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] This application relates to the field of computers, and in particular, to a method and apparatus for controlling the execution of an operating system, an embedded system, and a chip.

Background Art

[0002] Currently, devices such as servers, personal computers, and industrial computers often use a system architecture of hardware devices such as CPLD (Complex Programmable Logic Device), EC (Embedded Controller) chips, or hardware logic devices such as control chips in addition to an operating system to realize the control of the device. However, the use of hardware logic devices such as CPLD, EC chips, and control chips will inevitably lead to an increase in the cost of the system. In addition, due to the increase in the above-mentioned hardware logic devices, interaction between devices in the system is required, which has a significant impact on the execution efficiency of the operating system. Regarding the problem of low execution efficiency of the operating system in the related art, no effective solution has been proposed yet.

Summary of the Invention

Problems to be Solved by the Invention

[0003] Embodiments of this application provide a method and apparatus for controlling the execution of an operating system, an embedded system, and a chip for at least solving the problem of low execution efficiency of the operating system in the related art.

Means for Solving the Problems

[0004] According to a first aspect, there is provided 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 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 provide an embedded system that realizes control to 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. The first operating system and the second operating system are executed based on the processor. 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 the execution of an operating system, the method including detecting the execution state of a first operating system during the execution process, where the first operating system and a second operating system are executed based on a 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 apparatus for controlling the execution of an operating system, including a first detection module configured to detect the execution state of a first operating system during the execution process, where the first operating system and a second operating system are executed based on a processor. Provided is an execution control device for an operating system, including a control module configured to control processor resources used by a first operating system based on an execution state.

[0008] According to a fifth aspect, further provided is a chip including at least one of a programmable logic circuit and executable instructions, which is executed by an electronic device and is configured to implement steps in an embodiment of any of the above methods. According to a fifth aspect, further provided is a BMC chip including a storage unit and a processing unit connected to the storage unit. In order to implement steps in an embodiment of any of the above methods, the storage unit is configured to store a program, and the processing unit is configured to execute the program.

[0009] According to a seventh aspect, further provided is a motherboard including at least one processor and at least one storage device configured to store at least one program. When at least one program is executed by at least one processor, the at least one processor is configured to implement steps in an embodiment of any of the above methods.

[0010] According to an eighth aspect, further provided is a server including a processor, a communication interface, a storage device, and a communication bus. The processor, communication interface, and storage device are configured to communicate with each other via the bus. The storage device is configured to store a computer program. When the processor executes the program stored by the storage device, the server is configured to implement steps in an embodiment of any of the above methods.

[0011] According to a ninth aspect, further provided is a non-volatile readable storage medium storing a computer program, which is configured to implement steps in an embodiment of any of the above methods when executed by a processor. According to the tenth aspect, there is provided an electronic device including a memory device and a processor, wherein a computer program is stored in the memory device, and the processor is configured to execute the computer program to implement the steps in any of the above method embodiments.

Advantages of the Invention

[0012] According to the present application, the first operating system and the second operating system are executed based on a processor, 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. Since both the first operating system and the second operating system are executed based on the same processor, an increase and arrangement of hardware are avoided, system costs are reduced, and during the execution process of the operating system, the processor resources used can be controlled, and the execution between systems can be assisted by reasonably utilizing the processor resources. Thereby, the technical problem of low execution efficiency of the operating system can be solved, and the technical effect of improving the execution efficiency of the operating system can be achieved.

Brief Description of the Drawings

[0013]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

Figure 15

Figure 16

Figure 17

Embodiments for Carrying Out the Invention

[0014] Hereinafter, the embodiments of the present application will be described in detail with reference to the drawings and embodiments. In addition, terms such as "first" and "second" in the specification, claims, and brief description of the drawings of the present application are used to distinguish similar objects and are not necessarily used to describe a specific order or chronological order.

[0015] Examples of the method provided by the embodiments of the present application can be executed on a server, a computer terminal, a device terminal, or a similar computing device. Taking execution on a server as an example, FIG. 1 is a schematic diagram of the hardware environment of an operating system execution control method 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 (the processor 102 includes, 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 above server may further include a transmission device 106 and an input / output device 108 having a communication function. Those skilled in the art can understand that the structure shown in FIG. 1 is for illustration purposes and does not limit the structure of the above server. For example, the server may include more or fewer assemblies than those shown in FIG. 1, or may have a different configuration with functions equivalent to those shown in FIG. 1 or having more functions 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 of the operating system execution control method according to the embodiments of the present invention. The processor 102 executes the computer programs stored in the storage device 104 to execute various functional applications and data processing, and implement the above method. The storage device 104 may include a high-speed random access storage device, and may also include one or more non-volatile storage devices such as magnetic storage devices, flash memories, or other non-volatile solid storage devices. In some examples, the storage device 104 may further include a storage device provided remotely from the processor 102, and these remote storage devices are connected to the server via a network. Examples of the above 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 via a network. Selectable examples of the above network may include a wireless network provided by a communication provider of a server. In one example, the transmission device 106 includes a Network Interface Controller (abbreviated as 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 a method for controlling the execution of an operating system applicable to the above hardware environment. FIG. 2 is a flowchart of the method for controlling the execution of an operating system according to an embodiment of the present application. As shown in FIG. 2, the flowchart includes Step S202 of detecting the execution state of the first operating system during the execution process, where the first operating system and the second operating system are steps S202 executed based on a processor, and Step S204 of controlling the processor resources used by the first operating system based on the execution state.

[0019] In the above step, the first operating system and the second operating system are executed based on a processor, 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. Since both the first operating system and the second operating system are executed based on the same processor, it is possible to avoid an increase and arrangement of hardware, reduce system costs, and also control the processor resources used during the execution process of the operating system, rationally utilize the processor resources to assist the execution between systems, thereby solving the technical problem of low execution efficiency of the operating system and achieving the technical effect of improving the execution efficiency of the operating system.

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

[0021] Taking the case where the first operating system and the second operating system are different types of operating systems as an example, the first operating system and the second operating system may be operating systems with different sensitivities 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 operating systems with different resource occupancy. For example, the first operating system may have a lower service occupancy and resource occupancy than the second operating system.

[0022] The above-mentioned first operating system and second operating system are two different types of operating systems arranged in the processor of an embedded system, that is, they may be, but are not limited to, embedded operating systems. The embedded operating system can be divided into a real-time operating system (RTOS) and a non-real-time operating system according to the sensitivity to response time. The real-time operating system may include, but is not limited to, Free RTOS (Free Real-Time Operating System) and RT Linux (registered trademark) (Real Time Linux). The non-real-time operating system may include, but is 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 for controlling, monitoring, or assisting the operation of machines and equipment. The embedded system is based on computer technology centered around applications, and software and hardware can be adjusted to meet the strict requirements of application systems for dedicated computer systems such as function, reliability, cost, volume, and power consumption. The embedded system defined from application objects is a combination of software and hardware and can also cover attached devices such as machines.

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

[0025] Optionally, in this embodiment, the above method for controlling the execution of the operating system can be executed by control logic implemented in the embedded system, but is not limited thereto. The control logic realizes the control, allocation, and scheduling of hardware and software resources such as heterogeneous dual operating systems, processors, and memory devices in the embedded system.

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

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

[0028] Optionally, in this embodiment, the control of the processor resources may be to control one of them alone, 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 operations such as release, occupation, allocation, and recovery, but is not limited thereto. Based on the execution state of the first operating system in the execution process, in order to reasonably control the used processor resources, the resource utilization rate and the execution efficiency of the operating system can be improved.

[0029] In an exemplary embodiment, the detected execution state can determine the controlled processor resources. For example, when the service state is detected, the adjustment of the operating service can be controlled, and when the system state is detected, the use of the processor core can be controlled. Furthermore, different detection objects can be set based on the processor resources that need to be controlled. For example, when the operating service is adjusted, the service state can be detected, and when it is necessary to control the use of the processor core, the system state can be detected.

[0030] When the first operating system executes an operating service, the service state can reflect the execution status of the first operating system. Or, if it is necessary to control the operating service in the operating system, the service state of the operating service can be detected. For example, in step S202 above, the service state included in the execution state of the target operating service executed by the first operating system based on the processor can be detected, but it is not limited thereto.

[0031] Optionally, in this embodiment, the target operating service may be an operating service with certain requirements for the execution performance and operating environment of the system, but it is not limited thereto. For example, a fan control service with certain requirements for execution time, a log tracing service with certain requirements for data storage space, an interface switching service with certain requirements for response speed, and a hardware interface waveform signal simulation service.

[0032] Optionally, in this embodiment, the service state of the operating service can indicate the execution status of the operating service in each dimension, such as whether the operating service is interrupted or executed to a certain extent (for example, whether the execution time reaches a threshold value or the execution result reaches a predetermined result), but it is not limited thereto. When the target service state reaches the target service state, that is, when the operating service is executed to a certain extent, control operations that match the target service state can be performed on the service, thereby realizing control suitable for the current service state such as the migration of the operating service from one operating system to another, the start and stop of the operating service, and the suspension and recovery of the operating service. For example, in step S204 above, when 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 service state is reached, such as when the operating service is interrupted and executed to a certain extent (for example, the execution time reaches the threshold or the execution result reaches a predetermined result), the target operating service in the first operating system is released, and the second operating system continues to execute the target operating service. Therefore, it is realized that the operating service alternately executes in the operating system, and finally, the operating service can be executed in an operating system 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 first interrupt request sent by the second operating system to the first operating system is obtained, it is determined that the service state is the target service state, and the first interrupt request is used to request to inherit the target operating service. Or, the service state of the target operating service executed by the first operating system may be that the target operating service reaches the 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 the target service state.

[0035] Optionally, in this embodiment, when the target operating service performs the conversion of the operating system may be determined by the second operating system, but is not limited thereto. When the second operating system determines to inherit the target operating service, a first interrupt request may be sent to the first operating system to indicate that it inherits the target operating service. When the first interrupt request is obtained, 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 in response to the first interrupt request, the second operating system inherits the execution of the target operating service.

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

[0037] Optionally, in this embodiment, when the target operating service performs the conversion of the operating system may be determined by the service attributes of the target operating service itself, but is not limited thereto. When the target operating service is executed until the service attribute reaches the target service attribute, 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 the execution of the target operating service is taken over by the second operating system.

[0038] In an exemplary embodiment, the qualification for the second operating system to take over the target operating service may be determined by establishing a determination mechanism, but is not limited thereto. For example, when the first interrupt request is obtained, in response to the first interrupt request, it is determined whether the second operating system takes over the target operating service. When the second operating system takes over the target hardware controller, the target operating service is released.

[0039] Optionally, in this embodiment, when a first interrupt request is obtained, the target operating service executed by the first operating system does not have to be immediately released. Instead, it is determined whether the second operating system will inherit the target operating service, the eligibility of the second operating system to inherit the target operating service is judged, and when it is determined that the second operating system will inherit the target operating service, the target operating service executed by the first operating system is released.

[0040] In the mechanism for judging the eligibility of the second operating system 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 reject inheriting the target operating service. For example, after determining whether the second operating system will inherit the target operating service, if the second operating system does not 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 rejects inheriting the target operating service.

[0041] Optionally, in this embodiment, the rejection by the second operating system of inheriting the target operating service may be notified or indicated to the second operating system by means of sending an interrupt request between systems, but is not limited thereto. Optionally, in this embodiment, when the second operating system does not inherit the target operating service, it is not necessary to send a second interrupt request. The first operating system does not release the target operating service but continues to execute the target operating service. In this way, the second operating system cannot inherit the target operating service.

[0042] After sending a second interrupt request to the second operating system and rejecting the second operating system from inheriting the target operating service, the first operating system continues to execute the target operating service until the second operating system meets the inheritance conditions of the target operating service (for example, the service attribute reaches the target attribute). After that, the first operating system releases the target operating service to the second operating system and notifies the second operating system to inherit and execute it.

[0043] After releasing the target operating service executed by the first operating system, the second operating system can actively detect that the target operating service has been released and can inherit the target operating service. Alternatively, when the second operating system actively sends a first interrupt request to request to inherit the target operating service, the second operating system can directly inherit the target operating service by default unless it receives a second interrupt request that rejects the inheritance of the target operating service within a certain period, thus improving the inheritance efficiency of the target operating service.

[0044] When releasing the target operating service executed by the first operating system, the second operating system can actively send an interrupt request to notify the second operating system that the target operating service has been released. For example, send a third interrupt request to the second operating system, and 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 is used to execute the target operating service in response to the third interrupt request.

[0045] When the service attribute of the target operating service reaches the target service attribute, if the first operating system actively releases the target operating service, the first operating system 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 inherits and executes the target operating service.

[0046] FIG. 3 is a schematic diagram of the inheritance process of the operating service according to the 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 to inherit the target operating service executed by the first operating system. If the first operating system permits the second operating system to inherit the target operating service, the first operating system releases the target operating service, and the second operating system inherits the target operating service and executes the target operating service in the second operating system. If the first operating system rejects the second operating system's request to inherit the target operating service, the first operating system sends a second interrupt request to the second operating system to reject the second operating system's request to inherit the target operating service, and continues to execute the target operating service in the first operating system.

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

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

[0049] When the system state reaches the target system state, that is, when the operating system has been executed to a certain extent, control operations that match the target system state can be performed on the processor cores used by the operating system, and ultimately, the rational allocation and utilization of processor cores can be realized. For example, in step S204 above, 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 into the scheduling resource pool of the second operating system. The scheduling resource pool includes the processor cores in the processor assigned 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 the operating system being interrupted or executed to a certain extent (for example, the execution time reaches a threshold, the execution result reaches a predetermined result, or 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. Therefore, the alternate use of processor cores between operating systems can be realized, and ultimately, the processor cores can be utilized more rationally.

[0051] The system state of the first operating system reaching the target system state may be that the first operating system is interrupted by the second operating system. For example, when the second operating system obtains the fourth interrupt request sent to the first operating system, it is determined that the system state is the target system state, and the fourth interrupt request is used to request to occupy the target processor core. Or, the system state of the first operating system reaching the target system state may be that the system attributes of the first operating system reach the target system attributes. For example, when the system attributes of the first operating system reach the target system attributes, it is determined that the system state is the target system state.

[0052] Optionally, in this embodiment, when the target processor core performs the conversion of the operating system may be determined by the second operating system, but is not limited thereto. When the second operating system determines to inherit the target processor core, it can send a fourth interrupt request to the first operating system to indicate that it inherits the target processor core. When obtaining the fourth interrupt request, the system state of the first operating system has already reached the target system state. In response to the fourth interrupt request, the target processor core is released, and the second operating system inherits the target processor core and can be considered to add it to the scheduling resource pool for use.

[0053] Optionally, in this embodiment, after the second operating system obtains the fourth interrupt request sent to the first operating system, the data currently being executed in the first operating system can be pushed onto the stack. The first operating system enters the 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 a 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 allocated to it is higher than a certain threshold, or detect whether the remaining amount of resources of the core allocated to it is sufficient to execute the next process. When 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 needs additional processor cores, and the second operating system can actively send a fourth interrupt request to the first operating system to request to occupy the target processor core, thereby reducing its execution pressure and assisting in the execution of the next process.

[0055] In an alternative embodiment, when the second operating system (e.g., Linux) detects that the resource occupancy rate of the core 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). After the first operating system (RTOS) receives the fourth interrupt request, it stores the service site where it is currently executing (e.g., pushes the execution data onto the stack), and then releases the target processor core it uses. The second operating system (Linux) occupies the target processor core and allocates threads that need to be executed to the target processor core, or schedules the 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 length of the system execution time, the execution result, and the execution load, etc. The system execution time reaching the target system attribute may mean that the system execution time reaches a predetermined length of time, but is not limited thereto. The system execution result reaching the target service attribute may mean that the operating system executes a certain predetermined execution result, but is not limited thereto. The system execution load reaching the target system attribute may mean that the resource occupancy rate of the operating system is below or about to fall below the lower limit of a predetermined resource occupancy rate, but is not limited thereto.

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

[0058] In an exemplary embodiment, the qualification for the second operating system to occupy the target processor core may be determined by establishing a determination mechanism, but is not limited thereto. For example, when a fourth interrupt request is obtained, in response to the fourth interrupt request, it is determined whether the second operating system occupies the target processor core. If the second operating system occupies the target processor core, the target processor core is released.

[0059] Optionally, in this embodiment, when a fourth interrupt request is obtained, it is not necessary to immediately release the target processor core. Instead, it is determined whether the second operating system occupies the target processor core, a determination is made as to whether the second operating system is eligible to occupy the target processor core, and if it is determined that the second operating system is 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 the eligibility of the second operating system 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 reject occupying the target processor core. For example, if the second operating system does not occupy the target processor core, a fifth interrupt request is sent to the second operating system, and the fifth interrupt request is used to indicate that the second operating system should reject occupying the target processor core.

[0061] Optionally, in this embodiment, the rejection by the second operating system of occupying the target processor core may be notified or indicated to the second operating system by way of sending an interrupt request between systems, but is not limited thereto. Optionally, in this embodiment, when the second operating system does not occupy the target processor core, it is not necessary to send a second interrupt request. The first operating system does not release the target processor core but continues to occupy it, so that the second operating system cannot occupy the target processor core.

[0062] After sending a fifth interrupt request to the second operating system and rejecting the second operating system's attempt to occupy the target processor core, the first operating system continues to occupy the target processor core until the second operating system meets the target processor core occupancy conditions (e.g., the system attributes reach the target system attributes). After that, the first operating system releases the target processor core to the second operating system and notifies the second operating system to take over and execute.

[0063] Figure 4 is a schematic diagram of the process of occupying a processor core according to an embodiment of the present application. As shown in Figure 4, the first operating system is executed based on the target processor core. During the execution process, the second operating system sends a second interrupt request to the first operating system to request to occupy the target processor core it uses. When the second operating system is permitted to occupy it, the target processor core is released, and the second operating system occupies the target processor core and adds it to the scheduling resource pool. If the second operating system is not permitted to occupy it, a fifth interrupt request is sent to the second operating system to reject it.

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

[0065] When the first operating system actively releases the target processor core to be used, it can actively send an interrupt request to the second operating system to notify the second operating system that the target processor core has already been released. For example, it can send a sixth interrupt request to the second operating system, and the sixth interrupt request is used to indicate that the first operating system has already released the target processor core. The second operating system is used to add the target processor core into the scheduling resource pool in response to the sixth interrupt request.

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

[0067] In an alternative embodiment, when the first operating system (e.g., RTOS) determines during the execution process that there is no thread requiring scheduling (e.g., the resource occupancy rate of the operating system is lower than or about to be lower than a predetermined lower limit), it can trigger an active sleep of the first operating system (RTOS). The first operating system (RTOS) sends a sixth interrupt request to the second operating system (e.g., Linux), and then stores the execution context (e.g., pushes the execution data onto the stack) and goes to sleep. After receiving the sixth interrupt request, the second operating system (Linux) adds the target processor core into its scheduling resource pool for scheduling and use.

[0068] In a selectable application scenario, a dual operating system based on a multi-core processor CPU is installed in the chip. The first operating system may be, but is not limited to, an RTOS. 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. FIG. 5 is a schematic diagram 1 of the control process of processor resources according to an embodiment of the present application. As shown in FIG. 5, the RTOS wakes up and executes periodically. The RTOS and Linux alternately occupy and schedule CPU core 0. In the time slices (T4, T5) when the RTOS schedules CPU core 0, Linux generates an interrupt to inherit CPU core 0 at time T4-1 (corresponding to the above fourth interrupt request), and puts the RTOS to sleep. In this case, the RTOS stores the context on the stack and sleeps, and then releases CPU core 0 to Linux for inheritance. After the scheduling of Linux is completed, at time T5-1, the RTOS generates an interrupt to preempt CPU core 0 and wakes up the RTOS. The RTOS starts to enter the round-robin mode from time T5-1, occupies CPU core 0, and schedules it.

[0069] In this embodiment, the inheritance of operating services between systems and the occupation of the processor may be independent, but are not limited to this. For example, only the operating service is inherited, or only the processor core is occupied. The occupation may also be simultaneous occupation, that is, not only the operating service is inherited, but also the processor core may be occupied.

[0070] In an alternative embodiment, taking the operating service as the device control service as an example, the process of the second operating system inheriting the processor resources of the first operating system will be described. According to this embodiment, a startup control process of the operating system is provided, and the process includes the following. In step A, in order to control the execution state of the target device, the first operating system running on the first processor core of the processor controls the hardware controller of the target device via the first bus.

[0071] For devices such as servers, personal computers, and industrial computers, a specific device can be arranged to perform or execute related operations. In related technologies, usually after the system is powered on, these devices start to operate. However, after the system is powered on, the operating system running on the processor can normally take over a specific device after a certain period and control the execution state of the specific device. During the startup process of the operating system, the specific device is uncontrollable.

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

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

[0074] In order to solve at least part 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, and different operating systems of an embedded system are executed on different processor cores of a processor. The response speeds of different operating systems are different. In a situation where the second operating system fails to start, restart, or cannot control the execution state of a specific device, the execution state of the specific device can be controlled by a second operating system whose response speed is higher than that of the second operating system, thereby avoiding a situation where the execution state of the specific device cannot be controlled, without the need to add costs, and having excellent scalability.

[0075] In this embodiment, in a situation where the second operating system fails to start, restart, or cannot control the execution state of a specific device, in order to control the execution state of the target device, the first operating system executed on the first processor core of the processor controls the hardware controller of the target device via the first bus. The target device described in this specification may be a fan or other device that needs to be executed when the system starts up. 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, instead of a CPLD, an EC chip, and a custom chip, a conventional first operating system (e.g., an RTOS system) is used to reduce the hardware cost and at the same time realize the control of the device by software, so it has excellent scalability.

[0076] For example, a dual system of an RTOS system and a Linux system is realized based on a BMC dual core, and a fan is realized based on a multi-core system. Utilizing the high real-time characteristic of the RTOS system, during the startup process of the Linux system, instead of a CPLD, an EC chip, and a custom chip, the RTOS system controls the fan, that is, it inherits the control process for the fan and controls the running state of the fan at a sufficient speed.

[0077] Step B: Boot to start the second operating system on the second processor core of the processor. When the system is powered on or the second operating system restarts, in order for the second operating system to execute on the second processor core, it can be booted to start the second operating system on the second processor core of the processor. In this specification, starting the second operating system on the second processor core refers to scheduling the second processor core to the second operating system, and the system file or mirror file of the operating system can be stored in the chip where the processor is located, or in a storage device other than the chip, such as an external RAM (Random Access Memory).

[0078] Step C: After the second operating system is started, in order to inherit the control process of the target device, the second operating system inherits the hardware controller via the first bus. After the startup of the second operating system is completed, the execution state of the target device can always be controlled by the first operating system. To execute multiple operating systems on a multi-core processor, data interaction between the multiple operating systems is required. Considering that it is convenient for one operating system to execute overall control of the device, the second operating system can also inherit the control process of the target device. For example, the second operating system can inherit the hardware controller via the first bus. The method by which the second operating system inherits the control process of the target device may be that after the second operating system is started, the second operating system sends a device inheritance request to the first operating system. For example, an interrupt request is sent via the second bus, requesting to inherit the hardware controller of the target device. The first operating system can receive the device inheritance request sent from the second operating system and pass the control process of the target device to the second operating system. Furthermore, operations related to passing the control process of the target device can be executed. For example, the execution of a service (process) that controls the execution state of the target device can be stopped.

[0079] For example, after the Linux system is fully started, the RTOS system passes the control process of the fan to the Linux system, and the Linux system controls the fan. The above process may also be executed after the system is powered on. That is, using the startup method of a multi-core dual system, to facilitate early intervention in fan control, first, the RTOS system is started. After the Linux system is fully started, for control, the RTOS system passes the control process of the fan to the Linux system.

[0080] In an exemplary embodiment, before the first operating system running on the first processor core of the processor controls the hardware controller of the target device via the first bus, after powering on the chip where the processor is located, the method further includes waking up the first processor core via the processor, and running the bootloader program of the first operating system on the first processor core to boot 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. The startup control method in this embodiment may be executed in the initial startup stage or the real-time execution stage. For the initial startup stage, when the system is powered on, the initial startup process starts, that is, power on the chip where the processor is located, wake up one core for the boot operation of the operating system after the system is powered on, and the remaining cores are temporarily in the sleep state. The awakened core may be the first processor core.

[0082] Optionally, after powering on, the system first executes a preset core scheduling policy (boot policy), that is, the core scheduling policy is executed by the processor cores of the processor. The core scheduling policy may be stored in the RAM or Norflash (non-volatile flash memory) in the SOC (System on Chip). The scheduling policy is flexibly arranged according to different design needs. Its main function includes specifying the initial processing resources (processor cores) that need to be executed by different operating systems and determining the boot process of heterogeneous 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 by the boot loader program so that the first operating system starts on the first processor core. 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, it is a specific program in a Boot Rom, and the specific program refers to the code for booting so that the operating system starts. It belongs to the boot loader program. The Boot Rom is a small mask ROM (Read-Only Memory) or write-protected flash memory incorporated into the processor chip in the CPU chip.

[0084] In the initial startup stage, the boot loader program can improve the startup success rate of the operating system by booting so that the operating system starts on the corresponding processor core, and at the same time, prepares for the real-time execution stage. In an exemplary embodiment, the step of controlling the hardware controller of the target device via the first bus by the first operating system running on the first processor core of the processor is the step of executing the first control task of the first operating system on the first processor core. The first control task includes the step of being used to control the hardware controller, the step of reading the sensor data of the designated sensor corresponding to the target device by the first processor core, and the step of transmitting 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 according to the device control command.

[0085] When the operating system controls the hardware controller of the target device, it may be that the control task (service) in the processor core where the operating system runs controls the hardware controller to execute. The control tasks described in this specification can refer to the corresponding control tasks. Regarding the hardware controller of the target device, the first control task (first control process) of the first operating system can be executed on the first processor core, and the hardware controller can be controlled by the first control task.

[0086] The control of the hardware controller may be performed based on the sensor data of the sensor. If the target device is different, the parameters affecting its execution may be different, and the sensor data obtained accordingly may also be different. The target device may be a device that starts to execute immediately after the chip is powered on, and the corresponding sensor is the designated sensor. There are multiple types of designated sensors including, but not limited to, at least one of a temperature sensor, a humidity sensor, a noise sensor, etc. Since the first control task is executed on the first processor core, the first processor core can read the sensor data of the designated sensor. The sensor data of the designated sensor can be stored in the storage space within the designated sensor or in the storage space designated by the designated sensor. In this embodiment, the reading position of the sensor data of the designated sensor is not limited.

[0087] The sensor data of the specified sensor that has been read may be sensor data within a certain period, may be all sensor data after the startup of the target device, or may be sensor data that satisfies other time constraints. After acquiring the sensor data of the specified sensor, the first control task can control the execution state of the target device based on the sensor data of the specified sensor. The control of the execution state of the target device can be realized by the following method. The first control task sends a device control command to the hardware controller of the target device, and the hardware controller controls the execution state of the target device based on the device control command.

[0088] Optionally, the first control task can determine the expected execution state of the target device based on the sensor data of the specified sensor. When the current execution state of the target device is different from the expected execution state, the above device control command can be generated, and by controlling the device control command, the execution state of the target device can be adjusted to the expected execution state. The above device control command may be sent to the hardware controller of the target device via the first bus. Since the first bus is the same as that in the foregoing embodiment, the description thereof is omitted here.

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

[0090] The first control task can determine the expected execution state of the target device based on the sensor data of the specified sensor. The expected execution state may be indicated by the parameter values of the execution parameters of the device. The execution parameters of the device may be parameters for controlling the execution state of the target device. If the types of the devices are different, the corresponding execution parameters of the devices are also different. For example, the execution parameter of the fan may be the rotation speed, and the execution parameters of other types of devices may be other execution parameters. The expected execution state can correspond to the target parameter value of the execution parameter of the target device.

[0091] After determining the target parameter value of the execution parameter of the target device, the above device control instruction can include the target parameter value. That is, the first control task sends the device control instruction including the target parameter value to the hardware controller. The method of sending the device control instruction to the hardware controller is the same as that in the foregoing embodiments, so the description is omitted here.

[0092] Since the parameter value of the execution parameter of the target device is determined based on the sensor data and the device control instruction includes the determined parameter value, the control accuracy of the device can be improved. In an exemplary embodiment, the step of determining the target parameter value of the execution parameter of the target device based on the sensor data of the specified sensor by the first control task includes, when the target device is a fan, the step of determining the target parameter value of the execution parameter of the fan based on the sensor data of the specified sensor by the first control task.

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

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

[0095] Controlling the state of the fan may also be quickly controlling the execution state of the fan in a scenario of powering on the system, a scenario of restarting the system, or other scenarios, thereby improving the real-time performance of fan control. In an exemplary embodiment, when the target device is a fan, the step of determining the target parameter value of the execution parameter of the fan based on the sensor data of the specified sensor by the first control task is, when the target device is a fan and the specified sensor is a temperature sensor, the step of determining the target rotation speed value of the rotation speed of the fan based on the sensor data of the temperature sensor by the first control task, and the rotation speed of the fan is positively correlated with the temperature detected by the temperature sensor.

[0096] In the scenario where the target device is a fan, the designated sensor may be a temperature sensor, and the number of such temperature sensors may be one or more. The placement location of the temperature sensor is selectively chosen, and if the temperature sensors are different, the placement locations will also be different. Optionally, the sensor data of the temperature sensor is used to indicate the temperature detected by the temperature sensor. Accordingly, the first task can be to determine the target rotation speed value of the fan's rotation speed based on the sensor data of the temperature sensor. In this specification, the rotation speed of the fan has a positive correlation with the temperature detected by the temperature sensor.

[0097] When the number of temperature sensors is plural, the maximum temperature detected by the plurality of temperature sensors can be determined based on the sensor data of each temperature sensor, and the rotation speed of the fan may be determined by the maximum temperature detected by the plurality of temperature sensors. Compared with determining the rotation speed of the fan based on the average temperature detected by the plurality of temperature sensors, the execution safety of the device can be ensured. In the scenario where the number of fans is plural, the rotation speed of each fan can be determined based on the maximum temperature or the average temperature detected by the temperature sensor adapted to each fan.

[0098] For example, instead of a processing unit such as a CPLD, an EC chip, and a custom chip, the rotation speed of the fan can be controlled by a first operating system (for example, an RTOS system) (the control of the BMC fan can be performed in real time). When the system is powered on for the first time, the first processor core (for example, CPU0, and the first processor core may be woken up by hardware) can be woken up, and the first processor core executes a bootloader program (for example, a specified program in the Boot Rom), loads and starts the first operating system. The first processor core reads various sensor data related to temperature, controls the fan (for example, controls the rotation speed of the fan), and completely simulates the function that the above processing unit completes the control of the fan. When controlling the rotation speed of the fan, the first operating system can adjust the rotation speed of the fan by calculating the PWM value based on the temperature sensor. By the above method, in the startup process of the second operating system, the rotation speed of the fan can be controlled by the first operating system.

[0099] In an exemplary embodiment, the step of booting the second operating system to start on the second processor core of the processor includes, for the first processor core, executing a two-stage program loader to wake up the second processor core by the two-stage program loader, and for the second operating system to start on the first processor core, executing the general-purpose bootloader of the second operating system by the second processor core.

[0100] In this embodiment, when starting the operating system, the Second Program Loader (abbreviated as SPL) can be loaded into an internal memory such as a Static Random-Access Memory (SRAM) inside the SOC. The SPL can load the Universal Boot Loader (abbreviated as U-Boot) into the Random-Access Memory (abbreviated as RAM). The second-stage program loader can boot to load the second operating system, and can also boot to load the first operating system.

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

[0102] Note that the second-stage program loader is the code executed in the first stage of the general-purpose boot loader program. For execution, it can transfer the code of the second stage of the general-purpose boot loader program to the system memory (System RAM, off-chip memory). The general-purpose boot loader program is open-source software that follows the GPL (General Public License) contract and can be regarded as a bare-metal synthesis routine.

[0103] For example, after powering on the system, in order for the RTOS system to run as fast as possible, the processor first wakes up the CPU0 core, and then uses the program in the Boot Rom to boot so that the RTOS system starts. During the startup process of the RTOS system, the SPL continues to load U-Boot, and U-Boot boots on the CPU1 so that the second operating system starts until the Linux system starts successfully.

[0104] Note that the Boot Rom is the internal ROM specific program of the chip (for example, the SOC chip) and is the boot code of U-Boot. The Boot Rom reads the startup information of the hardware (for example, the settings of the DIP switch), reads the uboot-spl code (that is, the SPL) from the specified startup medium (for example, SD, MMC, etc.), and the SPL is mainly used to initialize the external RAM and the environment, and load and execute the actual U-Boot mirror image into the external RAM. The external RAM may be a 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 executes the general-purpose boot loader program by the second processor core to boot the second operating system in the corresponding processor core, ultimately improving the convenience and success rate of the operating system. As a selectable example, the startup process of the multi-core dual system will be described below using the RTOS system and the Linux system as an example.

[0106] To take over the fan management as soon as possible, the RTOS system is started as fast as possible. After the startup of the Linux system is completed, the Linux system takes over the fan control process. The startup process of the multi-core dual system is When initially powering on the system, step 1 of waking up CPU0, CPU0 executes the specified program in the Boot Rom and loads and boots the RTOS system in step 2, During the startup process of the RTOS system, to boot U - Boot, step 3 of waking up CPU1 and starting the fan control program (FanCtrl_RTOS_APP) in the first operating system, CPU1 booting U - Boot includes the SPL stage and the U - Boot stage, and step 4 of entering the SPL stage by calling SPL, In the SPL stage, SPL boots so that U - Boot starts in step 5, In the U - Boot stage, it includes step 6 of loading the Linux core (CPU1~CPUN) and starting the fan control program (FanCtrl_Linux_APP) in the BMC service program and the second operating system.

[0107] According to this selectable example, during the startup and execution process of the dual - system, first, the RTOS system is started to control the fan. After Linux starts, the second operating system takes over the fan control process. Finally, when powering on the system, it ensures that the fan is controlled at a high speed, improving the fan control efficiency. In an exemplary embodiment, after the step where the second operating system takes over the hardware controller via the first bus, when the second operating system waits for a restart, the second operating system wakes up the first operating system via the second bus. For the first operating system to take over the control process of the target device, it includes the step of the first operating system taking over the hardware controller via the first bus and the step of controlling the second operating system to restart.

[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. In order to take over the control process of the target device, the first operating system takes over the hardware controller. 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 restarts, it takes over the control process of the target device by waking up the first operating system, thereby improving the control reliability of the device. In an exemplary embodiment, when the second operating system waits for a restart, the second operating system sends a system wake-up interrupt to the first operating system via the second bus. The system wake-up interrupt includes steps used to wake up the first operating system.

[0110] The wake-up of the first operating system can be achieved by an interrupt between cores. When the second operating system is waiting for a reboot (e.g., system crash, receiving a reboot command), the second operating system can send a system wake-up interrupt to the first operating system to wake up the first operating system. The system wake-up interrupt may be an active wake-up interrupt. After inheriting the hardware controller, the first operating system can control the second operating system to reboot. After the second operating system reboots, it can inherit the hardware controller again. Since the process of inheriting the hardware controller is the same as that in the foregoing embodiments, the description thereof is omitted here.

[0111] In an exemplary embodiment, the first operating system may have a higher priority for the occupancy of the processor core assigned to it, but is not limited thereto, or which operating system is currently using the processor core assigned to the first operating system may be determined by negotiation between the operating systems, but is not limited thereto. 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 is woken up and executed, it is possible to detect whether the target processor core is released. If it is released, the first operating system is executed based on the target processor core. If it is not released, a seventh interrupt request can be sent to the second operating system to request that the second operating system release the target processor core. After the second operating system releases the target processor core in response to the seventh interrupt request, the first operating system is executed based on the target processor core. For example, when the target processor core in the processor has already been added to the scheduling resource pool of the second operating system and the first operating system is woken up and executed, it is detected whether the target processor core is released. The scheduling resource pool includes the processor core assigned to the second operating system. When it is detected that the second operating system has already released the target processor core when the first operating system is woken up, the first operating system is executed based on the target processor core.

[0112] Optionally, in this embodiment, the fact that the target processor core has already been added to the scheduling resource pool of the second operating system may indicate that the target processor core is already occupied, but is not limited thereto. In this case, when the first operating system is woken up and executed, the second operating system can actively release the target processor core. Further, the second operating system can continue to occupy the target processor core until the first operating system actively requests it to release the target processor core.

[0113] Optionally, in this embodiment, the first operating system detects whether the target processor core is released. If it detects that the target processor core is not released, it can 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 sends a seventh interrupt request to the second operating system. The seventh interrupt request is used for the second operating system to read 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. Optionally, in this embodiment, after receiving the seventh interrupt request, the second operating system can directly release the target processor core, but is not limited thereto, or it can determine whether to release the target processor core, and then can decide whether to immediately release the target processor core to the first operating system, or it can also release the target processor core to the first operating system after obtaining the execution result by continuous execution, but is not limited to these.

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

[0115] In the execution process of the operating system, the interaction of service data can be carried out, and the interaction process can be realized by means of a collaborative transmission method based on the memory space and interrupt requests, but is not limited thereto. Between operating systems, data is transmitted by the memory space, and commands are notified to each other by interrupt requests. For example, the service data generated in the process of the first operating system being executed based on the processor is obtained, the service data is stored in the memory space in the processor, and an eighth interrupt request is sent 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 memory space. The second operating system is used to read the service data from the memory space in response to the eighth interrupt request.

[0116] Alternatively, in this embodiment, the service data generated in the process of the first operating system being executed based on the processor is stored in the memory space in the processor, notified to the second operating system by the 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 operating systems may be all the data that needs to be transmitted between systems in the process of the operating system executing the operating service, but is not limited thereto. For example, it is process data of the service, result data of the service, and the like. Optionally, in this embodiment, the storage space in the processor may be a dedicated storage location arranged for the interaction process between operating systems, but is not limited thereto, and is called shared memory. The shared memory can be continuously re-allocated according to the operating system (that is, each operating system corresponds to a part of the dedicated shared memory), but is not limited thereto.

[0118] The eighth interrupt request for the second operating system to request to read service data from the storage space may include information (such as a memory address) of the shared memory corresponding to the first operating system. 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. Taking the transmission of the interrupt request in the form of a hardware module mailbox as an example, a mailbox channel is established between the first operating system and the second operating system, the service data is read and written by the storage space, and the interrupt request is transmitted by the mailbox channel.

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

[0120] Optionally, the first operating system and the second operating system may be a real-time operating system or a non-real-time operating system. The first operating system and the second operating system may be a single-core operating system or a multi-core operating system. The target data is the data to be transmitted, the target virtual channel is a part of the idle memory space, and the first operating system transmitting 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 transmitted to the target virtual channel.

[0121] Step b: Send an interrupt notification message (the above-mentioned 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. The interrupt notification message containing the address of the target virtual channel is used to notify the second operating system to read the target data from the target virtual channel. The interrupt notification message can be triggered by software or by hardware.

[0122] Step c: The second operating system obtains 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 analyzes the address of the target virtual channel from the interrupt notification message in response to the interrupt notification message, then locates the target virtual channel in the memory based on the analyzed address, obtains the target data from the target virtual channel, and realizes the interaction of data between the first operating system and the second operating system.

[0123] In the above steps, when multiple operating systems to be executed by a processor need to transmit data to each other, a first operating system that transmits data transmits target data to a target virtual channel in the processor memory, and transmits an interrupt notification message to a second operating system. A second operating system that receives data acquires the target data from the target virtual channel in response to the interrupt notification message, thereby solving the problems of wasting resources in the process of inter-core communication and high dependence on the operating system, reducing resource waste in the process of inter-core communication, and achieving the effect of reducing dependence on the operating system.

[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 is configured to store service data, and the metadata storage area is configured to store the size and occupied state of each storage unit in the data storage area. Optionally, the target virtual channel is composed of one or more storage units in the storage area, and the metadata storage area may be divided into the same number of storage chips as the number of storage units. Each storage chip is configured to record the size and occupied state of one storage unit. The size of the storage unit may be indicated by the start address and end address of the storage unit, or may be indicated by the start address and the length of the storage unit. The occupied state includes an occupied state and an unoccupied state, and may be indicated by the numerical value of the idle flag.

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

[0126] Note that in order to ensure that the target data is continuously written to the memory, the written target virtual channel needs to have an idle storage space 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 state of each storage unit recorded in the metadata storage area can be read, and an idle storage unit that meets the data storage needs can be found therefrom.

[0127] For example, when 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 storage units required is determined based on the length of the target data, and a plurality of consecutive idle storage units that meet the storage needs are found therefrom to form a target virtual channel.

[0128] For example, the sizes of the respective memory units are equal, and the data storage area obtains a plurality of virtual channels with different sizes by combining the memory units in advance. Each virtual channel is composed of a combination of one or more memory units. The occupancy state of each virtual channel recorded in the metadata storage area is read, and an idle virtual channel whose length is greater than the length of the target data, that is, a target virtual channel, can be found from among them. Note that when the system software needs to request a 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, in order to ensure that the length of the data transmitted each time is not greater than the maximum length of the data stored in the virtual channel, the system software can transmit the data to be transmitted in several times, and finally, smooth communication can be ensured.

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

[0130] That is, after the second operating system extracts the target data from the memory unit corresponding to the target virtual channel, in order not to affect the use of the target virtual channel by other systems or tasks, the state of the memory unit corresponding to the target virtual channel is set to the idle state. In an exemplary embodiment, the step in which the first operating system transmits target data to a target virtual channel in the processor memory includes the step in which the driver layer of the first operating system receives the target data, determines a virtual channel that is in an idle state in the memory, and obtains the target virtual channel, and the step of 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 driver layer. After receiving the target data to be transmitted, the driver layer, in order to avoid requesting that another system use the target virtual channel during the data writing process, after finding the target virtual channel, sets the state of the target virtual channel to an occupied state, and then writes the target data to the target virtual channel.

[0132] In an exemplary embodiment, when the first operating system includes an application layer, the application layer is provided with a man-machine interface. Before the step in which the driver layer of the first operating system determines a virtual channel that is in an idle state in the memory, the application layer of the first operating system receives the data to be transmitted input by the user through the man-machine interface, packages the data to be transmitted in a predetermined format, obtains the target data, and calls a data writing function to transmit the target data to the driver layer through a predetermined communication interface, the step in which the predetermined communication interface is provided in the driver layer.

[0133] Optionally, the application layer fills the data to be transmitted according to a predetermined format to obtain target data. Next, it generates the ipidev of the device file at the / dev path of the system. When the application needs to read and write data from the driver layer, it can first open the device file / dev / ipidev using the open function attached to the system. Next, it can use the write function attached to the system to transmit the target data from the application layer to the driver layer. The driver layer puts the data into the 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 obtaining the target data from the target virtual channel in the memory in response to the interrupt notification message includes the second operating system triggering an interrupt processing function based on the interrupt notification message, the interrupt processing function determining the target virtual channel from the memory, and obtaining the target data from the target virtual channel.

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

[0136] Optionally, the interrupt processing function sends a task notification to wake up the target task for extracting data. The target task first searches for the target virtual channel from the shared memory through 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 function flag that indicates a target function. The step of determining a target virtual channel from the memory by an interrupt processing function and obtaining target data from the target virtual channel is a step of obtaining a function flag and a target virtual channel from the memory by the interrupt processing function, and then transmitting the address information of the target virtual channel to a target application program that matches the function flag. The target application program is a target application program in the application layer, and the step of the target application program calling a data reading function to transmit the address information to the target application program through a predetermined communication interface. The predetermined communication interface is provided in the driver layer. To execute the target function, the target application program processes the target data based on a processing function that matches the function flag.

[0137] Optionally, after the second operating system receives an interrupt notification message, the application layer calls a corresponding interrupt processing function to search for a target virtual channel from the memory, obtains the address information of the target virtual channel, and then generates a device file ipidev in the / dev path of the system. When the application layer needs to read and write data from the driver layer, first, the open function attached to the system can be used to open the device file / dev / ipidev, and then the read function attached to the system can be used to read the target data in the target virtual channel. That is, the driver 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 target virtual channel is set to an idle state.

[0138] Note that different application programs in the application layer can realize different functions by using target data. In the memory, function flags for indicating the target functions realized by the application programs with the target data are stored. Optionally, the function flags may be Net and Cmd. In the case of system initialization, Net, Cmd, and the application program PID are registered with the drive device. The drive layer can find the PID of the application program based on the received NetFn and Cmd, and send the data to the corresponding application program based on the PID.

[0139] For example, NetFn = 1 and Cmd = 1 indicate that the first operating system and the second operating system send "hello word" to each other. Initialize an array at the start of the system. There are a total of three columns in the array. The first column is NetFn, the second column is Cmd, and the third column corresponds to the processing function of NetFn and Cmd, denoted as xxCmdHandler. For example, when the second operating system receives a message sent from the first operating system, obtain NetFn and Cmd from the message. If it is determined that NetFn = 1 and Cmd = 1, execute the corresponding processing function HelloCmdHandler of "hello word" to complete the corresponding function.

[0140] In an exemplary embodiment, the data storage area includes a plurality of memory channels, each memory channel is composed of one or more storage units, the metadata storage area stores a plurality of records, each record is used to record the metadata of one memory channel, and the metadata of each memory channel includes at least the channel ID of the memory channel, the size of the memory channel, and the occupied state of the memory channel. The first operating system reads the records in the metadata storage area, determines at least one idle storage unit in the storage area whose total space is greater than or equal to the length of the target data based on the read records, and the step of obtaining the target virtual channel includes traversing the records stored in the metadata storage area and determining whether there is a first target record indicating that the memory channel is in an idle state and the size of the memory channel is greater than or equal to the length of the target data. If there is a first target record, determining the memory channel indicated by the channel ID in the first target record as the target virtual channel.

[0141] Note that the data storage area can be divided into n virtual memory channels, and the sizes of each memory channel do not have to be equal. That is, the sizes of the n virtual memory channels are successively 20* m, 21*m, 22*m, 23*m …… 2n-1*m, where m is the size of one storage unit. Also, 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] Here, uint32_t Flag indicates the state of the memory channel. For example, 0xA5A5A5A5 indicates that this channel is non-idle; otherwise, it is idle. uint16_t ChannelId indicates the channel ID, uint8_t SrcId indicates the source CPU ID, where the source CPU refers to the CPU for writing data to the memory channel. uint8_t NetFn and uint8_t Cmd are functional 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 points to the starting address of the memory channel, and uint8_t CheckSum points to the checksum. When the first operating system needs to send data, it calculates the check value of the data to be sent by the checksum algorithm and sends the check value to the second operating system. When the second operating system receives the data and the check value, it calculates the check value based on the received data by the same checksum algorithm, compares the calculated check value with the received check value. 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, and this structure record is stored at the starting position of the shared memory according to the method where the channel ID increases. After the system is powered on, these structure records are initialized. When the initialization Flag is 0, it indicates that this channel is idle. The initialized ChannelId is 0, 1, 2... n-1 in sequence, the initialized ChannelSize is the size of the corresponding virtual memory channel, and the initialized pData indicates the starting 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 based on the size of the target data to be transmitted, and searches for a virtual channel that satisfies the following two conditions from all memory channels. Those conditions are as follows. The idle flag Flag in the channel structure IpiHeader is not equal to 0xA5A5A5A5 (i.e., the channel is not in an idle state), and the channel size ChannelSize in the channel structure IpiHeader is greater than or equal to the size of the target data (i.e., the memory size can satisfy the storage needs of the target data). After finding a target virtual channel that satisfies the above conditions, set the state of the channel to non-idle, that is, set the idle flag Flag in the channel structure IpiHeader to 0xA5A5A5A5, and then copy the target data into the target virtual channel.

[0145] In an exemplary embodiment, when a memory channel is occupied, the metadata of the memory channel further includes the ID of the source CPU core of the target data and the ID of the destination CPU core of the target data. The step in which the second operating system reads the record in the metadata storage area and determines the target virtual channel based on the read record is to traverse the record in the metadata storage area and determine whether there is a second target record. The second target record is a step in which the memory channel is in an occupied state, the ID of the destination CPU core is the ID of the CPU core of the second operating system, and the ID of the source CPU core is not the ID of the CPU core of the second operating system. When there is a second target record, the step of determining the memory channel indicated by the channel ID in the second target record as the target virtual channel is included.

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

[0147] Note that when the idle flag Flag is indicated by 1 bit, 0 indicates that the channel is idle, and 1 indicates that the channel is not idle. When Flag changes from the original 0 to 1, after the system reads Flag, it is considered that the channel is not idle, resulting in communication anomalies. In this embodiment, the idle flag Flag is set to a special character of multiple bits such as 0xA5A5A5A5. Since the probability that multiple bits are simultaneously changed to the special character is much smaller than the probability that 1 bit is changed, the change of the bits in the storage medium can be prevented from affecting the value of Flag, and finally, the communication security is improved.

[0148] In an exemplary embodiment, a mapping table is stored in the metadata storage area. The mapping table has a plurality of records, each of which is used to record the occupied state of one storage unit. The first operating system reads the records in the metadata storage area, determines at least one idle storage unit in the data storage area where the total space is greater than or equal to the length of the target data, and the step of obtaining the target virtual channel includes determining a predetermined number of storage units that the target data should occupy, sequentially scanning each record from the initial position of the mapping table, and when scanning a continuous predetermined number of target records, determining the continuous storage units indicated by the predetermined number of target records, where the target records characterize that the storage unit is in an idle state, and determining the continuous storage units as the target virtual channel.

[0149] Note that in order to facilitate data storage and extraction, when the operating system transmits service data, it is necessary to occupy continuous storage units in the memory. Therefore, first, it is necessary to determine the number of storage units in the memory request instruction. Since the memory space of each storage unit is the same, a predetermined number of continuous storage units required can be calculated based on the size of the required memory space, and the predetermined number is denoted as numb.

[0150] Optionally, the first operating system traverses the records from the index position in the mapping table. The index position may be the start position of the mapping table. Starting from the start position of the mapping table, each record in the mapping table is queried in sequence to determine whether there are continuous records of numy or more idle memory pages. If there are records that meet the above conditions, the correspondence with the memory pages is recorded to determine the continuous storage units in the processor, and the continuous storage units are determined as the target virtual channel, and data is written to the target virtual channel.

[0151] In an exemplary embodiment, the interrupt passing message includes the starting address of a continuous memory unit and a predetermined number. The step in which the second operating system reads a record in the metadata storage area and determines a target virtual channel based on the read record includes the step of sequentially scanning each record from the initial position of the mapping table, and when scanning to find that the starting address of the continuous memory unit is recorded, determining, as the target virtual channel, the memory unit indicated by the scanned address and a number of continuous memory units obtained by subtracting 1 from the predetermined number.

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

[0153] In an exemplary embodiment, during the process of recording continuous target records scanned by a counter and sequentially scanning each record from the initial position of the mapping table according to the number of memory units, when currently scanning a target record, control is performed to increment the counter by 1, and when currently scanning a non - target record, control is performed to clear the counter to 0. Optionally, determine whether there are a predetermined number of consecutive target records based on the magnitude relationship between the value of the counter and the number of required memory units, that is, whether there are a predetermined number of consecutive memory units. Optionally, the count of the counter is denoted as cntr. When the scanned memory unit is idle, increment cntr by 1. When the scanned memory unit is not idle, it is in the idle state, clear the accumulated number of consecutive memory units cntr to 0, and continuously search for idle consecutive memory units starting from one address after the memory unit until cntr is equal to numb, indicating that idle consecutive memory units satisfying the memory needs have been found. After scanning the entire mapping table, if there is no cntr greater than or equal to numb, the current dynamic memory request fails, indicating that there are no predetermined number of consecutive memory units.

[0154] In an exemplary embodiment, a first operating system reads records in a metadata storage area, determines at least one idle memory unit in a data storage area where the total space is greater than or equal to the length of the data based on the read records, and before obtaining a target virtual channel, the method includes a step where the first operating system sends a memory request instruction and locks the memory of the processor. The memory request instruction is used to request the use of the processor's memory. If the memory lock is successful, the method further includes a step of reading records in the mapping table.

[0155] Optionally, a memory request instruction is an instruction that is sent from an operating system running on a processor and requests to use the memory of the processor. Note that in order to prevent multiple operating systems from causing conflicts by simultaneously requesting to use the memory of the processor, when an operating system sends a memory request instruction, first, it locks the memory of the processor, and as long as the lock is successful, it can request to use the memory. The lock operation refers to an exclusive operation of the memory request. After the current operating system successfully locks it, other servers do not have the right to request to use the processor memory unless it is unlocked.

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

[0157] Before the processor executes, it is necessary to initialize the metadata storage area and the data storage area in the processor. 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 completed. When the variable MemReady is 0xA5A5A5A5, it indicates that the initialization has already been completed and the memory can be dynamically requested or released normally. The member variable MemReady of the structure MallocMemInfo_T indicates whether it is locked or not.

[0160] Optionally, when reading that the variable MemLock is 0, it indicates that there is no system or task requesting the memory, that is, the memory is currently in a locked state. When reading that the variable MemLock is 0xA5A5A5A5, it indicates that there is a system or task requesting the memory, and after this request is completed, it is necessary to request the memory again, indicating that the current lock request fails.

[0161] In an exemplary embodiment, when locking the memory, if a situation where the lock fails occurs, after waiting for a predetermined length of time, it requests to lock the memory again until the lock is successful. For example, the predetermined length of time may be 100 microseconds. In an exemplary embodiment, if the lock request fails and the number of repeated requests exceeds a predetermined number, it indicates that the processor's memory is in an unallocatable state at the current length of time, and the request operation is stopped. For example, the predetermined number may be 3. When the number of lock requests is greater than 3, a message indicating that the current memory is unavailable can be returned to the operating system that sends the request.

[0162] Optionally, if there is a target virtual channel available for the first operating system in the memory space of the processor, the first operating system stores the target data to be transmitted in the corresponding target virtual channel. In an exemplary embodiment, the first operating system updates the occupancy state of the memory space of the processor based on the data writing status of the first operating system, that is, changes the continuous target memory space from an unoccupied state to an occupied state. At the same time, the memory is unlocked so that other systems or tasks can request the memory.

[0163] In an exemplary embodiment, the method unlocks the memory if it does not scan a continuous predetermined number of target records. Optionally, after scanning the records in the mapping table, if a predetermined number of continuous idle storage units are not detected, the memory of the processor cannot provide sufficient space memory pages for the first operating system, indicating that 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 means of a software interrupt. The step of sending an interrupt notification message to the second operating system by means of a software interrupt includes writing the interrupt number and the ID of the 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] Optionally, a software interrupt is an interrupt by software, and the software can send an interrupt to the CPU core that executes itself and can also send an interrupt to other CPU cores. A predetermined register may be the GICD_SGIR register. To generate a software interrupt, the software can write an SGI (Software Generated Interrupts) interrupt number and a destination CPU ID to the GICD_SGIR register. The SGI interrupt number is a software interrupt number for communication between cores.

[0166] In heterogeneous operating systems of multi-cores, to have maximum compatibility with the current resource allocation method, numbers 8 to 15 (a total of 8 interrupts) are used to indicate an inter-core interrupt vector table. When the first operating system is an RTOS operating system and the second operating system is a Linux operating system, one of the realizable allocation methods of 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 means of a hardware interrupt. Optionally, a hardware interrupt refers to an interrupt generated by a hardware device, which may be a private peripheral interrupt or a shared peripheral interrupt. Note that a hard interrupt is an interrupt by hardware outside the CPU, has randomness, and a soft interrupt is an interrupt by software executing an interrupt instruction in the CPU and is preset. This embodiment does not limit the generation method of the interrupt notification message.

[0169] According to an alternative embodiment, a method for sharing memory is provided. The method includes the following steps. Step 101, receive a memory request instruction, and lock the memory of the processor. The memory request instruction is used to request to use the memory of the processor.

[0170] Optionally, the memory request instruction is an instruction sent from an operating system running on the processor to request to use the memory of the processor. In order to prevent multiple operating systems from causing conflicts by simultaneously requesting to use the memory of the processor, when the operating system sends a memory request instruction, first lock the memory of the processor. As long as the lock is successful, it can request to use the memory. The lock operation refers to an exclusive operation of the memory request. After the current operating system successfully locks, no other server has the right to request to use the processor memory unless it unlocks.

[0171] In the method for sharing memory provided by the embodiments of the present application, before locking the memory of the processor, the method further includes a step of determining whether the memory is currently in a locked state, where the locked state indicates that the memory is in a state of being requested for use, and if the memory is currently in an unlocked state, a step of locking the memory. Optionally, since multiple operating systems or multiple tasks may cause conflicts by simultaneously requesting to use the memory, the memory of the processor is locked by only one system or task within the same time quantum. Therefore, as long as it is detected that the memory is currently in a locked state, the current operating system can lock the memory.

[0172] Optionally, by determining whether a predetermined variable stored in the memory is a predetermined value, it is determined whether the memory is in a locked state. If the predetermined variable is not the 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 lock is successful. Otherwise, the predetermined variable is the predetermined parameter, at the current time, the memory is in a locked state, and another system or task other than the operating system requests the memory space, indicating that the lock fails.

[0173] In the method of sharing the memory, after determining whether the memory is currently in a locked state, if the memory is currently in a locked state, it includes the step of determining that the lock of the memory fails, and if the lock of the memory fails, after a predetermined length of time, until the lock of the memory is successful or the number of lock requests is greater than a predetermined number, it further includes the step of requesting to lock the processor's memory again.

[0174] Optionally, when locking the memory, if a situation where the lock fails occurs, after waiting until a predetermined length of time, it requests to lock the memory again until the lock is successful. For example, the predetermined length of time may be 100 microseconds. In an exemplary embodiment, if the lock request fails and the number of repeated requests exceeds a predetermined number, it indicates that the processor's memory is in an unallocatable state at the current length of time, and the request operation is stopped. For example, the predetermined number may be 3. If the number of lock requests is greater than 3, a message indicating that the current memory is unavailable can be returned to the operating system that sends the request.

[0175] Step 102, if the lock of the memory is successful, read the occupied state of the memory, and based on the occupied state of the memory, determine whether there is an idle target memory space in the memory. The size of the target memory space is equal to or greater than the size of the memory requested by the memory request instruction. Upon successful request for a lock, the operating system requests memory in the processor, optionally scans for information to record the occupied state of the memory, determines whether there is a target memory space, that is, determines whether the memory is in an unoccupied state and whether there is a continuous memory space that meets the memory usage needs. Meeting the memory usage needs means that the size of the memory space is greater than or equal to the size of the memory requested by the operation.

[0176] Note that when requesting memory, discontinuous memory spaces can also be used. A pointer can be added behind one or more minimum memory blocks to indicate the next minimum memory block obtained by the request. At the same time, when reading and writing data, reading and writing of data between data blocks is realized based on the storage address and the pointer. This embodiment does not limit the form of the target memory space.

[0177] Step 103: If there is a target memory space in the memory, feedback the address information of the target memory space to the sender of the memory request instruction, update the occupied state of the memory, and unlock the memory. The sender refers to the operating system for sending the memory request instruction. Note that in the case of communication between cores, the operating system transmits and receives data through shared memory. In the process of data transmission and reception, it is necessary to determine the address information of the requested memory space to store the data using the address returned by the requested memory.

[0178] Optionally, if there is a target memory space for the operating system in the memory space of the processor, transmit the address information of the continuous space of the target 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 occupancy state of the memory space of the processor is updated based on the data writing status of the operating system, that is, the target memory space is changed from an unoccupied state to an occupied state, and the lock state before dynamically requesting the memory is released so that other operating systems can request to use the memory space of the processor.

[0179] By the above steps, a memory request instruction is received and the memory of the processor is locked. The memory request instruction is used to request to use the memory of the processor. If the locking of the memory is successful, the occupied state of the memory is read, and based on the occupied state of the memory, it is determined whether there is an idle target memory space in the memory. The size of the target memory space is not less than the size of the memory requested by the memory request instruction. If there is a target memory space in the memory, the address information of the target memory space is fed back to the sending side of the memory request instruction, the occupied state of the memory is updated, and the memory is unlocked. Thereby, the problems of low usage efficiency, low flexibility, and excessive dependence on the operating system of the shared memory among multiple cores are solved, the flexibility and usage efficiency of the shared memory are improved, and the effect of reducing the dependence on the operating system is achieved.

[0180] In the method for sharing the memory, the memory includes a metadata storage area and a data storage area. The data storage area is configured to store service data, and a mapping table is stored in the metadata storage area. The mapping table is configured to record the occupied state of the data storage area. The step of reading the occupied state of the memory and determining whether there is an 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 a target memory space in the data storage area based on the record in the mapping table.

[0181] Query the occupied state of the memory by querying the records in the mapping table, selectively obtain the metadata storage area stored in the processor, and identify the mapping table in the metadata storage area. By traversing the records in the mapping table, read the occupied state of the data storage area, and determine whether there is a continuous memory space in the data storage area that is in the idle state and meets the memory usage needs.

[0182] In the memory sharing method provided by the embodiments 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, read the records in the mapping table from the metadata storage area, and based on the records in the mapping table, the step of determining whether there is a target memory space in the data storage area includes: determining a predetermined number of memory pages requested by a memory request instruction; scanning each record in sequence from the initial position of the mapping table; when scanning a continuous predetermined number of target records, determining that there is a target memory space in the memory, where the target record indicates that the memory page is in the idle state.

[0183] Note that the data storage area is divided into a plurality of allocation units according to the size of the same memory, and each allocation unit is denoted as one memory page. For example, when 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. The records in the mapping table are memory page records, each record of the memory page is used to record the occupied state of the memory page, and the number of records of the memory page 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, 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, and the records are recorded as the records of the memory pages. Combine the records of all memory pages into a mapping table. All the records of the memory pages in the mapping table are in one-to-one correspondence with all the memory pages of the data storage area. The record of each memory page indicates the allocation status of the corresponding memory page, that is, whether the memory page is occupied or not.

[0185] Optionally, since the service data that cooperates with the operating system needs to occupy consecutive memory pages in the processor, first, it is necessary to determine a predetermined number of memory pages in the memory request instruction. Since the memory space of each memory page is the same, based on the size of the required memory space, the predetermined number of consecutive memory pages required can be calculated, 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 record of the memory page from the index position in the mapping table. The index position may be the start position of the mapping table. Start from the start position of the mapping table, query each record of the mapping table in turn, and determine whether there are numb or more consecutive records of idle memory pages. If there is a record of a memory page that meets the above conditions, according to the correspondence between the record of the memory page and the memory page, the processor determines that there is a target memory space.

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

[0188] In the memory sharing method provided by the embodiments of the present application, the number of target records scanned by the counter is recorded. In the process of sequentially scanning each record from the initial position of the mapping table, when currently scanning a target record, the counter is controlled to increment by 1, and when scanning a non-target record, the counter is controlled to be cleared to 0. The non-target record indicates that the memory page is in an occupied state.

[0189] Optionally, according to the magnitude relationship between the value of the counter and the number of required memory pages, it is determined whether there are a continuous predetermined number of target records, that is, whether there is a target memory space. Optionally, the count of the counter is denoted as cntr. When a scanned memory page is idle, cntr is incremented by 1. When the scanned memory page is non-idle, it is in an idle state, and the accumulated continuous number of memory pages cntr is cleared to 0. Continuously search for an idle continuous storage unit from one address after the memory page until cntr is equal to numb. If an idle continuous memory page that meets the memory needs is found, it indicates that the entire mapping table has been scanned. If cntr is less than numb, the current dynamic memory request fails, indicating that there is no target memory space.

[0190] In the method for sharing a memory provided by an embodiment of the present application, when the initial position is the last position in the mapping table, the step of feeding back the address information of the target memory space to the transmitting side of the memory request instruction includes determining the last target record scanned in a continuous predetermined number of target records, and feeding back the start address of the memory page indicated by the last target record scanned to the transmitting side.

[0191] Optionally, when scanning the mapping table, the scanning method may start scanning from the first position or the last position of the mapping table. When the scanning method is to scan from the last position of the mapping table, if the numerical value cntr indicated by the counter is greater than or equal to a predetermined number numb, record the start address of the corresponding memory page of the last scanned memory page, and for the memory page, set the state of these memory pages to non-idle, and use the start address as the start address of the entire continuous memory page of the current memory request instruction.

[0192] In an exemplary embodiment, the address is fed back to the operating system that issues the memory request instruction, and the operating system performs a data writing operation on the memory based on the address information. In the method for sharing a memory provided by an embodiment of the present application, when the initial position is the first position in the mapping table, the step of feeding back the address information of the target memory space to the transmitting side of the memory request instruction includes determining the first target record scanned in a continuous predetermined number of target records, and feeding back the start address of the memory page indicated by the first target record scanned to the transmitting side.

[0193] Optionally, when the scanning method is to scan from the first position of the mapping table, if the value cntr indicated by the counter is greater than or equal to a predetermined number numb, the address recorded in the first scanned memory page is used as the starting address, and it is sent to the operating system that issues a memory request instruction. The operating system performs a data writing 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 sequentially scanning each record from the initial position of the mapping table, a predetermined variable stores the first target record in the scanned consecutive target records. Optionally, the predetermined variable refers to the variable of the mapping table for storing the address information of the initial position, denoted as offset. Each time an idle consecutive memory page is scanned, 1 is added to the value cntr indicated by the counter. When the value cntr indicated by the counter is greater than or equal to a predetermined number numb, the address information currently stored in offset is used as the address of the first target record.

[0195] In the memory sharing method provided by the embodiment of the present application, the occupied state of the memory is read, and based on the occupied state of the memory, after determining whether there is an idle target memory space in the memory, the method includes the step of unlocking the memory when there is no idle target memory space in the memory. Optionally, after scanning the records of the memory pages in the mapping table, if it is detected that there are no predetermined consecutive idle memory pages, that is, no target memory space, the memory of the processor cannot provide sufficient space memory pages for the first operating system, and the current dynamic memory request fails, indicating that the memory is to be unlocked.

[0196] In the method for sharing a memory 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. Currently, the step of determining whether the memory is in a locked state is a step 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 is a step of indicating that the memory is in a locked state. When the memory management information includes the predetermined information, it is a step of determining that the memory is currently in an unlocked state. When the memory management information does not include the predetermined information, it is a step of determining that the memory is currently in a locked state.

[0197] To determine whether the memory of the processor 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, based on it, determine whether the memory management information includes predetermined information. The predetermined information is used to indicate whether the memory is in a locked state. When the memory management information does not include the predetermined 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 method for sharing a memory 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 explain whether the memory is in a locked state, and the second field information is used to explain whether the initialization of the memory is completed. Before receiving a memory request instruction, 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. Optionally, initialize the record of the memory pages stored in the mapping table in the metadata storage area, and initialize the memory management information. Optionally, the memory management information is composed of first field information and second field information. That is, the first field information indicates whether it is locked, and the second field information is used to indicate whether the initialization is completed. Before requesting memory, set the memory management information 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 the initialization of the shared memory is completed, and the member variable MemReady (first field information) of the structure MallocMemInfo_T indicates whether it is locked. When MemLock is 0, it indicates that there is currently no system or task requesting memory, that is, it is not locked. When MemLock is 0xA5A5A5A5, it indicates that there is a system or task requesting memory, and after this request is completed, another system or task needs to request memory. When the variable MemReady is 0xA5A5A5A5, it indicates that the initialization has already been completed and the memory can be dynamically requested or released normally.

[0202] In the memory sharing method provided by the embodiments 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 the address information of multiple memory pages in the target memory space, and update the records of the memory pages in the mapping table area of the metadata storage area according to the correspondence between the memory pages and the records of the memory pages, and change it from the unoccupied state to the occupied state.

[0203] According to an alternative embodiment, a communication method between operating systems is provided. The method includes the following steps. Step 201, receive a memory request instruction of the first operating system and lock the memory of the processor. The memory request instruction is used to request to use the memory of the processor. In addition, in order to prevent a request failure caused by multiple operating systems simultaneously requesting the memory space of the processor, when the first operating system sends a memory request instruction, it requests to lock the memory of the processor, and as long as the request for locking is successful, the memory can be requested.

[0204] Optionally, determine whether to succeed in locking by determining whether a predetermined variable stored in the memory is a predetermined value. If the predetermined variable is not the predetermined parameter value, it indicates that there is no other system or task requesting the memory, and the locking is successful. Otherwise, the predetermined variable is the predetermined parameter, and at the current time, other systems or tasks other than the operating system request the memory space, indicating that the locking fails.

[0205] Step 202, when the lock of the memory is successful, read the occupied state of the memory, and based on the occupied state of the memory, determine whether there is an idle target memory space in the memory. The size of the target memory space is greater than or equal to the size of the memory requested by the memory request instruction. Optionally, if the lock request is successful, based on the memory request instruction issued by the operating system, scan the information recording the occupied state of the memory to determine whether there is a target memory space, that is, the processor determines whether there is a continuous memory space in the unoccupied state. In an exemplary embodiment, it is determined whether the size of the continuous memory space in the unoccupied state is greater than or equal to the size of the memory requested by the operating system, and a determination result is obtained.

[0206] Step 203, if there is a target memory space in the memory, feedback the address information of the target memory space to the first operating system, update the occupied state of the memory, and unlock the memory. Optionally, after the determination result indicates that there is a target memory space for the operating system in the processor's memory space, the address information of the continuous space of the target 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, that is, change the target memory space from the unoccupied state to the occupied state, and release the lock state before the dynamic request. Step 204, in response to the storage operation of the first operating system, store the target data in the target memory space, and send the address information of the continuous 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 the second operating system that cooperates with the first operating system, and notifies the second operating system to obtain the data.

[0208] Step 205, the second operating system receives an acquisition command to be sent based on the address information, and sends 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, the embedded system receives the command, and sends the target data stored in the target memory space to the second operating system.

[0209] By the above steps, the memory request command of the first operating system is received, and the memory of the processor is locked. The memory request command is used to request to use the memory of the processor. When the memory lock is successful, the occupied state of the memory is read, and based on the occupied state of the memory, it is determined whether there is an idle target memory space in the memory. The size of the target memory space is not less than the size of the memory requested by the memory request command. If there is a target memory space in the memory, the address information of the target memory space is fed back to the sending side of the memory request command, the occupied state of the memory is updated, and the memory is unlocked. In response to the storage operation of the first operating system, the target data is stored in the target memory space, and the address information of the continuous memory space is sent to the second operating system. The second operating system receives the acquisition command sent based on the address, and sends the target data stored in the target memory space to the second operating system, thereby solving the problems of low utilization efficiency, low flexibility, and excessive dependence on the operating system of the shared memory among multiple cores, achieving the effects of improving the flexibility and utilization efficiency of the shared memory and reducing the dependence on the operating system.

[0210] In an exemplary embodiment, when the first operating system reads and writes data using physical addresses and the second operating system reads and writes data using virtual addresses, the second operating system converts the address information of the target memory space into a virtual address, accesses the memory using the virtual address, and reads target data from the target memory space.

[0211] In inter-core communication, when data is transmitted and received via shared memory, the address returned by the dynamically requested memory is used. However, if the systems are different, the address systems used may also be different. For example, if the real-time operating system is the first operating system and the non-real-time operating system is the second operating system, in the real-time operating system, when accessing shared memory, the physical address can be directly used. In the non-real-time operating system, the physical address cannot be directly used to access shared memory, and the virtual address after mapping needs to be used. After the second operating system receives the address information of the target memory space, it is converted by the address information offset, mapped to a virtual address, and then operates based on the virtual address. Optionally, it is the virtual base address vBase of the shared memory under the non-real-time operating system (assuming the physical actual address of the shared memory is 0x96000000), and the physical base address pBase of the shared memory under the real-time operating system (i.e., 0x96000000).

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

[0213] In a real-time operating system, the address returned by the dynamically requested memory is the physical address pData. In a real-time operating system, Offset = pData - pBase. The data is sent from the real-time operating system to the non-real-time operating system. The non-real-time operating system accesses the dynamically requested shared memory vData = vBase + Offset using the address vData.

[0214] In an exemplary embodiment, the memory includes a metadata storage area and a data storage area. The data storage area is composed of a plurality of memory pages. Each memory page is used to store service data. A mapping table is stored in the metadata storage area. The mapping table includes a plurality of records. Each record is used to record the occupied state of one memory page. The steps of reading the occupied state of the memory and determining whether there is an idle target memory space in the memory based on the occupied state of the memory include: determining a predetermined number of memory pages requested by a memory request instruction; sequentially scanning each record from the initial position of the mapping table; and when scanning a continuous predetermined number of target records, determining that there is a target memory space in the memory, where the target record indicates that the memory page is in an idle state.

[0215] Optionally, obtain the metadata storage area stored in the processor, identify the mapping table in the metadata storage area, start from the index position in the mapping table, traverse the records of each memory page, query the records of each memory page in the mapping table in sequence, and determine whether there are a predetermined number or more consecutive records of memory pages that record idle memory pages. If there are records of memory pages that meet the above conditions, according to the correspondence between the records of memory pages and the memory pages, the processor determines that there is a target memory space.

[0216] In an exemplary embodiment, when the initial position is the last position in the mapping table, the step of feeding back the address information of the target memory space to the sending side of the memory request instruction includes determining the last target record scanned in a predetermined number of consecutive target records, and feeding back the start address of the memory page indicated by the last target record scanned to the sending side.

[0217] Optionally, when scanning the mapping table, the scanning method may start scanning from the first position or the last position of the mapping table. When 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, set these memory pages to non-idle, and use the start address as the start address of the entire consecutive memory pages of the current memory request instruction. In an exemplary embodiment, feedback the address to the operating system that issues the memory request instruction, and the operating system performs a data writing operation on the memory based on the address information.

[0218] This embodiment further provides a method for sharing memory. Before the operating system issues a memory request instruction, in order to prevent multiple operating systems from causing conflicts by simultaneously requesting the memory space of the processor, a lock request is required. The method includes steps of: determining whether the lock request is successful; when the determination result indicates that the lock of the dynamically requested memory is successful, calculating the number of consecutive memory pages that need to be allocated based on the size of the memory in the issued memory request instruction, and denoting the number of memory pages as nmemb; when the determination result indicates that the lock request fails, waiting until a certain time (100 microseconds) and then requesting again until the request is successful. If the number of lock requests is greater than or equal to a predetermined number (3 times), the memory is not requested.

[0219] In an exemplary embodiment, after a lock request is successful, the metadata storage area of the processor is initialized. The last position of the mapping table is denoted as offset, and the number of consecutive memory pages required is calculated based on the size of the memory space required 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 placed and denoted as cmemb. Next, the mapping table in the metadata storage area of the processor is obtained, and starting from the offset of the mapping table, the entire mapping table is scanned to record the correspondence between the memory pages stored in the mapping table and the memory pages in the data storage area, and consecutive idle memory pages are found. If the currently scanned memory page is in an occupied state, then offset = offset - cmemb. Next, the data cmemb of the consecutive idle memory pages accumulated by the counter is cleared to 0, and then consecutive idle memory pages are searched for again starting from the new offset position. If the memory is idle, that is, in an idle state, 1 is added to the value of the counter cmemb, offset = offset - 1, and the determination of the next memory page continues until cmemb is equal to nmemb, that is, when the data of the counter is equal to the size of the required memory space, it indicates that consecutive memory pages meeting the requirements have been scanned.

[0220] In an exemplary embodiment, the memory pages meeting the requirements are marked as occupied in the corresponding mapping table, and the starting address of the last found memory page is used as the starting address of the entire dynamically requested consecutive memory pages. The dynamically requested memory is unlocked, and the dynamic memory request this time is successful. In the process of scanning the entire mapping table, if the value of offset is less than 0, it indicates that there are no memory pages meeting the usage requirements of the operating system, the dynamically requested memory is unlocked, and the dynamic memory request this time fails.

[0221] In addition, if it is found that the space is not sufficient after dynamically requesting the space, its size can be dynamically adjusted. Optionally, a memory request instruction after update can be issued again to lock the memory. If the lock is successful, when the memory space requested by the memory request instruction after update becomes larger, after the continuous memory of the requested target, it is judged whether there is sufficient memory space. If so, the request is successful. When the memory space requested by the memory request instruction after update becomes smaller, a part of the memory space is released.

[0222] In this embodiment, a plurality of storage areas are divided, and the index position is used to dynamically request the space according to the size of the required space. After use, the space is released. In addition, if it is found that the space is not sufficient after dynamically requesting the space, its size can be dynamically adjusted, and finally, the flexibility and usage efficiency of the shared memory are improved. In this embodiment, FIG. 7 is a schematic diagram of the interaction process of service data according to the embodiment of the present application. As shown in FIG. 7, the first operating system generates service data during the execution process and determines that the service is required by the second operating system or needs to be transmitted to the second operating system. In this case, the first operating system stores the service data in the memory space and sends an eighth interrupt request to the second operating system. The second operating system reads the service data from the memory space in response to the eighth interrupt request and performs subsequent processing.

[0223] The first operating system may have different execution mechanisms, but is not limited thereto. For example, control is performed so that the first operating system is periodically executed based on a processor, or in response to a received wake-up request, control is performed so that the first operating system is executed based on a processor, or based on the degree of fitness between the operating service generated by the processor and the first operating system, control is performed so that the first operating system is executed based on a processor.

[0224] Optionally, in this embodiment, the execution mechanism of the first operating system may include, but is not limited to, periodic execution and trigger-based execution. Periodic execution is called the polling mode, and trigger-based execution is called the trigger mode. The trigger includes a trigger by a request to trigger the wake-up and execution of the first operating system by a wake-up request, and a trigger by a condition to trigger the wake-up and execution of the first operating system by the degree of fitness between the operating service and the first operating system, but is not limited thereto.

[0225] Optionally, in this embodiment, when the first operating system is periodically executed, the length of time of one execution cycle and the length of time between two execution cycles may be the same or different. During the length of time between two execution cycles, the first operating system is in a sleep state, and the second operating system can use the processor core assigned to the first operating system, but is not limited thereto. When the length of time of one execution cycle is the same as the length of time between two execution cycles, 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 time of one execution cycle is different from the length of time between two execution cycles, 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 greater than the length of time occupied by the second operating system, or the length of time occupied by the second operating system may be greater than the length of time occupied by the first operating system.

[0226] Based on different execution scenarios, different system functions can execute the first operating system using different execution mechanisms, but are not limited thereto. In order to execute the first operating system and improve the processing efficiency of operating services, a more compatible execution mechanism can be found more flexibly from the current execution scenario and system functions.

[0227] In an alternative embodiment, a wake-up policy for a first operating system (e.g., RTOS) in polling mode is provided. FIG. 8 is a schematic diagram 1 of the execution process of the 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, and the RTOS can be periodically woken up and executed based on a predetermined time. In the execution process of a multi-system (taking a dual system of Linux and RTOS as an example) in this mode, (T0, T1) = (Tn, T(n+1)), where n is a positive integer other than zero, that is, the dual system alternately occupies 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. In this time slice, the RTOS is in a sleep state and will execute accordingly according to the period in subsequent time slices.

[0228] Regarding the triggering method by a request in trigger mode, the wake-up request may be issued by a device connected to the first operating system, but is not limited thereto, or may be issued by the second operating system, but is not limited thereto. In an alternative embodiment, as an example of the apparatus triggering the wake-up and execution of the first operating system, a wake-up policy for the first operating system (e.g., RTOS) in trigger mode is provided. FIG. 9 is a schematic diagram 2 of the execution process of the first operating system according to an embodiment of the present application. As shown in FIG. 9, the trigger mode may be started by an interrupt from a device in the RTOS bus domain. The RTOS bus domain is connected to devices 0 to N. When the RTOS is in the sleep state, at a certain moment, it is assumed that device 0 triggers an interrupt to the RTOS, the RTOS is woken up, and after waking up, the RTOS first triggers an interrupt to preempt CPU core 0 from Linux. After receiving the interrupt, Linux first releases CPU core 0 and stores the context (pushes the data to be executed onto the stack). Next, the RTOS system schedules the CPU core 0 to process the operating service indicated by the interrupt triggered by device 0. Currently, when in the polling mode, the subsequent processing process is the same as the above polling mode, so the description is omitted here.

[0229] When the second operating system triggers the wake-up and execution of the first operating system, if the second operating system currently occupies the processor core assigned to the first operating system, it releases the processor core, and after waking up, the first operating system can use the processor core to process the operating service assigned to the second operating system.

[0230] In an alternative embodiment, the service executed by the first operating system may include, but is not limited to, a service for generating a hardware interface signal. This embodiment provides a process for generating a hardware interface signal, and the process includes the following steps. Step 11, obtain a request instruction by the first operating system.

[0231] In step 11, the request instruction may be an instruction for generating a hardware interface signal. For example, the hardware interface signal may be a PECI signal, and the request instruction may be a PECI request instruction based on the PECI protocol. Alternatively, the hardware interface signal may be a hardware interface signal of another protocol type, such as an HDMI (registered trademark) (high definition multimedia interface) signal, an RGMII (reduced gigabit media independent interface) signal, an SGMII (serial gigabit media independent interface) signal, a GPIO (general-purpose input / output) signal, an SPI (serial peripheral interface) signal, etc. Therefore, the request instruction may be a request instruction of another protocol type. For example, when the hardware interface signal is a GPIO signal, the request instruction is a GPIO request instruction. The present application does not particularly limit the selectable types of the request instruction and the hardware interface signal.

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

[0233] Optionally, the request command includes at least one field, each field may be indicated by a logical bit 0 or 1. Therefore, the corresponding conversion relationship between each field and the logical bit 0 or 1 is the logical bit information corresponding to the field. When the request command corresponds to multiple fields, the request command corresponds to multiple logical bit information. Note that each logical bit may be indicated by a combination of a high-level signal and a low-level signal. For example, for logical bit 0, it may be indicated by a combination of a high-level signal with a first predetermined time length and a low-level signal with a second predetermined time length. For logical bit 1, it may be indicated by a combination of a high-level signal with a second predetermined time length and a low-level signal with a first predetermined time length. 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 indicated by a waveform signal (the conversion between the high-level signal and the low-level signal is displayed as a waveform). Since the request command corresponds to multiple logical bit information, that is, 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: Generate a hardware interface signal corresponding to the request command based on multiple logical bit information and a timer. Optionally, the timer in step 13 may be a timing program of the first operating system, the timer may be a register in the chip where the first operating system is located, and the timer can provide at least a timing function and a counting function. This application uses the timing function and the counting function of the timer to combine multiple logical bit information to generate a hardware interface signal corresponding to the request command.

[0235] As something to note, taking as an example that the chip is a BMC chip and the hardware interface signal is a PECI signal, in the related art, in order to realize PECI communication between a BMC chip and devices such as a CPU, in the related art, the BMC chip itself needs to have the hardware logic design of a PECI controller, which causes the problem that the design cost of the BMC chip becomes high. That is, in the related art, in order to generate a PECI signal in the BMC chip, it is necessary to pre-realize the hardware logic design of the PECI controller in the BMC chip. In the present application, to generate a PECI signal in the BMC chip, only the first operating system is required, and it is not necessary to realize the hardware logic design of the PECI controller in the BMC chip. Therefore, the design difficulty and design cost of the BMC chip are reduced.

[0236] As can be seen from the content 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. First, the first operating system obtains a request command, then determines a plurality of logical bit information corresponding to the request command, and finally generates a hardware interface signal corresponding to the request command based on the plurality of logical bit information and a timer.

[0237] As can be seen from the above content, in this embodiment, the first operating system generates a hardware interface signal corresponding to a request command, achieving the technical effect of simulating and generating the hardware interface signal using a software method. Furthermore, the purpose that the chip itself does not have the hardware logic design of the related hardware interface signal is achieved, reducing not only the design difficulty of the chip but also the chip design cost.

[0238] Therefore, based on the fact that it is not necessary to implement the hardware logic design of the hardware interface signal on the chip, this embodiment achieves the purpose of generating the hardware interface signal by using a software system, reduces the design difficulty of the chip, and further solves the technical problem that in the related art, the chip itself needs to have the hardware logic design of the controller and the design cost of the chip is high.

[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 are executed 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 lower than the response speed of the service of the first operating system. Finally, the first operating system analyzes the request data to obtain a request instruction.

[0240] Optionally, before obtaining the request data, the second operating system can store the request data in a target memory (i.e., the storage space in the processor). After the storage of the request data is completed, the second operating system triggers the first request, and the first request is used to notify the first operating system to read the request data from the target memory. 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, and the transmission form of the response data is the same as the transmission form of the hardware interface signal. Next, 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, the first operating system triggers a second request, which is used to notify the second operating system to read the response data.

[0242] Take an example where 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 instruction request process, first, in the Linux system, upper-layer applications related to the PECI service (such as fault diagnosis and CPU temperature acquisition) selectively issue PECI request instructions, which include basic Ping() instructions, CPU temperature acquisition instructions, and MSR register (Machine Specific Register) information acquisition instructions, etc., but are not limited to these. The realization of the codes of different PECI request instructions is completed by 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 instruction into the target memory according to the PECI protocol specification. After all the request data is written into the target memory, the Linux system generates a first request for notifying the RTOS system. Here, the first request may be an SGI interrupt request (software generated interrupt, communication interrupt request between processor cores).

[0244] As something to note, in the process of storing the requested data in the target memory by the second operating system, the second operating system stores the requested data in the target memory according to the form of the first data structure. The first data structure includes at least the address of the device, the length of writing, the length of reading, the instruction code, and the request parameters. The address of the device is used to indicate the address of the target device. The target device is a device for generating response data based on the hardware interface signal. The instruction code is used to distinguish different request instructions. The length of writing is used to indicate the number of bytes from the start of the instruction code to the end of the requested data. The length of reading is used to indicate the number of bytes in the requested data including the completion code and the read data. The request parameters are used to indicate the parameters of the request instruction.

[0245] Regarding the instruction response process, the RTOS system receives the response data transmitted through the PECI path. Next, in order to convert the signal form of the response data from the form of the hardware interface signal to the form of the software signal, the RTOS system completes the analysis of the data. For example, it identifies the waveform change between the high-level signal and the low-level signal of the hardware interface signal, obtains the corresponding logical bit information, and obtains the software signal data based on the logical bit information. The instruction parameter structuring module adjusts the analyzed response data and writes it into the target memory. After all the analyzed response data is written, the RTOS system triggers a second request to notify the Linux system. Linux detects the second request, actively reads the analyzed response data stored in the target memory, processes the data, and then returns it to the upper-layer 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) and a Flash memory. In an alternative embodiment, after generating a hardware interface signal corresponding to a request command based on logical bit information and a 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 the hardware interface signal to a voltage conversion device and obtain the target hardware interface signal output from the voltage conversion device. Optionally, the above voltage conversion device may be a CPLD, 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 service is applicable not only to replacing the PECI interface to generate PECI signals, but also to other hardware interfaces. As can be seen from the above content, the first operating system and the second operating system are combined, and the data interaction in the embedded system is realized by means of inter-core interrupt and memory sharing. In the RTOS system, a waveform generation function module for request commands is constructed, and the communication of the hardware interface signal between the embedded system and an external device is realized by means of software simulation. Note that the high real-time performance of the RTOS system is fully utilized to ensure the timing accuracy during the simulation of the request command waveform, and it has the characteristics of flexibility and high efficiency. The design difficulty of the chip can be significantly reduced. Since software simulation is used to generate the hardware interface signal, more possibilities are provided by the optimized design between the communication function and other service functions in the embedded system. At the same time, since the controller in the chip specifically configured to realize the hardware interface signal communication is omitted, the design cost and manufacturing cost of the chip can be reduced.

[0249] In an alternative embodiment, the services running on the first operating system may include, but are not limited to, a serial port switching service. This embodiment provides a process for switching serial ports, which includes the following steps. Step 21, when it is detected that 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.

[0250] Optionally, when the user starts to switch the serial port, the second operating system can detect whether it receives a serial port switching command initiated by the user. The serial port switching command includes information about the target serial port to be switched. For example, the serial port switching command includes the serial port number of the target serial port to be switched.

[0251] In an alternative example, the format of the serial port switching command may be <switch_command_app-n number-t sleep_time>. Here, switch_command_app indicates the switching command program, -n indicates the serial port number of the switched target serial port, the value of number may be 1, 2, or 3, -t indicates how much time it takes from when the command starts to when it sleeps before executing the switching operation, and the unit of sleep_time is seconds.

[0252] Note that when implementing serial port switching, currently, the serial ports capable of performing serial port switching can be numbered. Therefore, when performing subsequent serial port switching, the target serial port can be switched according to the serial port number. In an alternative embodiment, currently, the serial ports that can perform serial port switching include the BMC Linux system serial port, the server BIOS (Basic Input Output System) serial port, and the SMART NIC (network interface controller) serial port. Accordingly, 1 represents the BMC Linux system serial port, 2 represents the server BIOS serial port, and 3 represents the SMART NIC serial port.

[0253] Step 22: The first operating system executes serial port switching based on the serial port switching instruction. Optionally, when it is detected that the second operating system receives a serial port switching instruction, the second operating system immediately sends the serial port switching instruction to the first operating system. Note that the first operating system and the second operating system can each be executed on two processor cores, and the first operating system and the second operating system use communication between cores, which helps to improve the reliability of signal transmission in this way.

[0254] Note that the instruction response speed of the first operating system is much higher than that of the second operating system. In this way, the first operating system can quickly respond to the serial port switching instruction and complete the switching operation in a very short time. In short, instead of using a CPLD or FPGA, by running a first operating system and a second operating system on the same processor, a serial port switching software function is realized. When the second operating system receives a serial port switching command, the second operating system sends the serial port switching command into the first operating system. The first operating system realizes the switching of the serial port based on the serial port switching command. In the related art, it is necessary to connect each serial port by using a CPLD or FPGA, and then realize the switching of the serial port by means of a switch structure in the CPLD or FPGA, thus avoiding the need for hardware cost reduction. After receiving the serial port switching command, the first operating system can quickly complete the switching of the serial port in a very short time. Therefore, the technical method provided by this means can effectively reduce the serial port switching cost and effectively improve the serial port switching efficiency.

[0255] In order to enable the second operating system to realize the switching of the serial port, 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. Before the first operating system executes the switching of the serial port based on the serial port switching command, the first operating system obtains the analysis rule of the serial port switching command from the target storage device, and analyzes the serial port number of the target serial port in the serial port switching command based on the analysis rule to determine the device corresponding to the serial port number. The target serial port is the serial port of the device, and the target serial port is connected to the chip.

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

[0257] In order for the first operating system to quickly implement the switching of the serial port, 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, the parsing rule of the serial port switching command can be customized according to various chips or the motherboard of the server, and the parsing rule can be stored in the target storage device. The target storage device may be a storage medium such as an electrically erasable programmable read-only memory (eeprom) or a non-volatile memory (flash). Note that the target storage device may or may not be disposed within the chip. Storing the parsing rule by the target storage device improves the security of the data and can customize the parsing rule according to various chips and the motherboard of the server, so it has excellent programmability and scalability.

[0258] After the first operating system receives the serial port switching command, it reads the parsing rule of the serial port switching command from the target storage device, and then uses the parsing 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. 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] Note that the serial port switching instruction and the parsing rule can be set according to the type of the chip used and the types of the first operating system and the second operating system. In the serial port switching method provided by Embodiment 1 of the present application, the chip includes a serial data bus. Before the first operating system determines the address of the serial port of the device, the method further includes determining a plurality of devices connected to the serial port of the serial data bus, and mapping the serial ports of each device into the memory of the chip through the serial data bus to obtain the addresses of the serial ports of each device.

[0260] Optionally, the above chip further includes a serial data bus, and the TX and RX of the serial ports of the current plurality of devices are connected to the serial data bus. For example, the current serial ports include the BMC Linux system serial port (UART1), the server BIOS serial port (UART2), and the SMART NIC serial port (UART3). UART (Universal Asynchronous Receiver / Transmitter) refers to a general-purpose asynchronous transceiver device. The serial data bus can map the TX and RX data of different serial ports of UART1, UART2, and UART3 into different address spaces of the BMC memory, that is, the above serial data bus maps the serial ports of each device into the memory of the chip. 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 three) mapped by the UART, interacts the data of one memory segment with the client, and achieves the purpose of simulating the CPLD hardware serial port switching circuit. In addition, if the serial ports of different devices cannot be distinguished, the developer cannot accurately identify which device's serial port has a problem during maintenance. Therefore, it is necessary to identify the abnormal location by switching the serial port.

[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, when the target output interface can be connected to the target intelligent network card, the intelligent network card detects whether to receive an access request to the target serial port, and when receiving an access request to the target serial port, the intelligent network card transfers the access request to the target serial port.

[0263] Optionally, the target output interface of the chip may be connected to the target intelligent network card. Next, the intelligent network card detects whether the user receives an access request to the target serial port. When receiving an access request to the target serial port, the target intelligent network card directly realizes access to the serial port of the device and can realize the SOL (Serial over LAN, data packet format and protocol specifications) function. By the above steps, the access efficiency to the serial port of the device is improved.

[0264] In an alternative 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, by the first operating system, an execution result of a serial port switching command, where the execution result is one of success or failure of the switching and transmitting, by the first operating system, the execution result to the second operating system.

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

[0266] In order to improve the success rate of serial port switching, in this embodiment, after the second operating system receives the execution result of the serial port switching command, if the execution result fails in execution, until the execution result succeeds in execution, or until the number of serial port switching times exceeds a predetermined number of times, the second operating system further includes the step of repeatedly executing the step of sending the serial port switching command to the first operating system. When the number of serial port switching times exceeds the predetermined number of times, the second operating system triggers a prompt signal, and the prompt signal is used to prompt the failure of serial port switching.

[0267] If the execution result of the serial port switching command fails in execution, until the execution result succeeds in execution, or until the number of serial port switching times exceeds a predetermined number of times, the second operating system needs to repeatedly execute the step of sending the serial port switching command to the first operating system. The predetermined number of times may be three times. When the number of serial port switching times exceeds the predetermined number of times, to prompt the failure of serial port switching and process this situation in a timely manner, the corresponding second operating system triggers a prompt signal.

[0268] Before the first operating system detects receiving a serial port switching instruction, after the second operating system is started, the second processor core triggers a first interrupt and transmits a first signal to the first operating system; the first operating system detects the execution states of a plurality of serial ports in the chip based on the first signal to obtain a detection result; the first processor core triggers a second interrupt and transmits the detection result to the second operating system by a second signal; and the second operating system receives the detection result to determine the number of serial ports in the chip that are normally executed.

[0269] After the second processor core triggers a first interrupt and transmits a first signal to the first operating system, the second processor core detects whether the first operating system receives the first signal. If the first operating system receives the first signal, the first operating system detects the execution states of a plurality of serial ports in the chip to obtain a detection result.

[0270] After the second operating system is started, the second processor core triggers a first interrupt (IPI interrupt, IPI, inter-processor interrupts, inter-processor interrupt) and transmits a first signal to the first operating system. The first operating system can know that the second operating system has been successfully started by the first signal, can interact with the second operating system normally, and the first operating system detects the execution states of a plurality of serial ports in the chip based on the first signal to determine whether all serial ports are normally executed.

[0271] After the first operating system detects the detection result, the first processor core triggers a second interrupt to send the detection result to the second operating system via a second signal. The second operating system determines the number of serial ports that can be switched according to the detection result (i.e., the number of the above-mentioned normally operating serial ports), and then performs serial port switching on those serial ports. At the same time, in order for the first operating system to realize serial port switching faster, after the detection of the first operating system is completed, the first operating system begins to close and waits for the reception of the serial port switching command sent from the second operating system.

[0272] In an alternative embodiment, when the first operating system is RTOS and the second operating system is Linux, the first operating system runs on CPU0, and the second operating system runs on CPU1. The preparation step before serial port switching is that when the Linux system running on CPU1 boots up to a specific stage, CPU1 triggers an IPI interrupt to notify the RTOS system on CPU0 that Linux has already booted up normally and can interact with Linux on CPU1 normally. After receiving the IPI interrupt from CPU1, the RTOS system starts the serial port switching controller program to check whether UART1, UART2, and UART3 are normal. Next, CPU0 triggers another IPI interrupt to notify the Linux operating system on CPU1 that the RTOS system has already booted up, and at the same time, the reported information includes the number of serial ports that can be switched in the RTOS operating system on CPU0. Next, the RTOS operating system on CPU0 begins to close and waits for the reception of the switching command issued from the operating system on CPU1.

[0273] When the second operating system is executed and there are abnormal situations, the server terminal issues a serial port command to the first operating system, and the first operating system executes the switching of the serial port based on the serial port switching command. Since the second operating system has many functions to execute and the amount of services it undertakes is large, there may be situations where it executes abnormally or needs to be restarted. When the second operating system executes abnormally, in order to ensure that the first operating system can normally execute the switching of the serial port, the server terminal can directly issue a serial port switching command to the first operating system. Note that the server terminal may also be a terminal in the server where the chip is located.

[0274] By the above steps, it is ensured that the first operating system can realize the switching of the serial port without depending on the second operating system, and the independence of the serial port switching by the first operating system is improved. In short, in the process of serial port switching provided by this embodiment, instead of using a CPLD or FPGA, the first operating system and the second operating system are executed by 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 into the first operating system. The first operating system realizes the switching of the serial port based on the serial port switching command, avoiding realizing the switching of the serial port by a hardware method, reducing the hardware cost. After receiving the serial port switching command, the first operating system can quickly complete the switching of the serial port in a very short time. Therefore, the above process can effectively reduce the serial port switching cost and effectively improve the serial port switching efficiency.

[0275] For a trigger based on conditions in the trigger mode, the compatibility between the current operating service and the first operating system can indicate whether the operating service generated by the processor is suitable for processing by the first operating system, but is not limited thereto. By allocating a suitable operating service to the first operating system, a reasonable allocation of the operating service 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 thereto. Detect the service information of the current operating service generated by the processor, and when it is detected that the compatibility between the service information and the first operating system is higher than the threshold of the compatibility, control 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 can be indicated by the compatibility between the service information of the operating service and the first operating system, but is not limited thereto. The service information may include any dimension with processing requirements, such as the response speed of the service, the resource occupancy rate of the service, the coupling degree of the service, the importance of the service, etc., but is not limited to them.

[0278] Optionally, in this embodiment, when the compatibility between the service information and the first operating system is higher than the threshold of the compatibility, it indicates that the operating service is suitable for execution on the first operating system. The threshold of the compatibility may be dynamically adjusted based on the current resource usage status or execution requirements of the first operating system, but is not limited thereto. Therefore, the adaptability and flexibility of the first operating system are higher.

[0279] In this embodiment, the service information of the current operating service generated by the processor can be detected by the following method, but is not limited thereto. The target response speed and / or target resource occupancy of the current operating service are detected. The service information includes the target response speed and / or 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. When the target response speed is below the speed threshold and / or the target resource occupancy is below the occupancy threshold, it is determined 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, the target response speed and / or 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 operation service regarding the response speed of the processor can be considered individually, or the requirements of the current operation service regarding the available resources of the processor can be considered individually. Furthermore, both can be considered comprehensively to allocate the current operating service.

[0281] In an alternative embodiment, the operating service and processing resources can be allocated to each operating system by the following method, but are not limited thereto. Based on the resource dynamic allocation rule, allocate a set of services to be allocated to the corresponding operating system in the embedded system. The resource dynamic allocation rule can dynamically allocate resources based on at least one of 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, but is not limited thereto. The embedded system includes a first operating system and a second operating system. The first operating system and the second operating system are executed by a processor, and the response speed of the first operating system is higher than that of the second operating system.

[0282] Determine the resource allocation result corresponding to a set of services to be allocated. The resource allocation result is used to indicate the processing resources corresponding to each allocated service among a set of services to be allocated of the processing resources of the processor. The processing resources of the processor include processor cores. Based on the operating system corresponding to each service to be allocated and the resource allocation result, allocate the processing resources of the processor to the first operating system and the second operating system.

[0283] During the execution process of the processor, a set of services to be allocated, that is, the services to be allocated to the first operating system and the second operating system, can be obtained. Since the dimensions such as response speed, resource occupancy rate of the service, degree of service coupling with other services, and importance of the service may be different for each service to be allocated, resource dynamic allocation rules can be pre-arranged. The resource dynamic allocation rules may include rules for allocating services, and in order to execute the services allocated to itself by the processing resources of the corresponding operating system, the services are allocated to the corresponding operating system. Optionally, in order to dynamically allocate resources, the resource dynamic allocation rules may include at least one of the response speed of the service, the resource occupancy rate of the service, the degree of service coupling, and the importance of the service. Different allocation rules may have corresponding priorities. For example, in descending order, the priorities are in turn the importance of the service, the coupling factor of the service, the response speed of the service, and the resource occupancy rate of the service. According to the resource dynamic allocation rules, a set of services to be allocated (or services to be allocated, different services to be allocated can correspond to different processes) is allocated to the corresponding operating system in the integration system, and the allocation result of the service can be obtained.

[0284] Optionally, based on response time constraints, the first operating system may be an operating system with definite fixed time constraints, and all processing processes (task scheduling) need to be completed within a certain time; otherwise, a system failure will occur. It may be a real-time operating system (abbreviated as RTOS) such as FreeRTOS or RTLinux, or a real-time operating system among other embedded systems. The second operating system does not have this feature. Generally, the second operating system uses a fair task scheduling algorithm. When the number of threads / processes increases, it is necessary to share CPU time, and task debugging becomes uncertain. Therefore, it can be said to be a non-real-time operating system, such as Contiki, HeliOS, Linux (full name GNU / Linux, a freely distributable Unix-based operating system), etc., or a non-real-time operating system in other embedded systems. The Linux system is a multi-user, multi-task, multi-thread, and multi-CPU operating system based on POSIX (Portable Operating System Interface).

[0285] Accordingly, the services assigned to the first operating system are usually real-time services. Real-time services refer to services that need to be scheduled within a certain period of time. Such services need to be processed by the processor at a sufficiently fast speed, and the processing results can control the production process within a certain period of time or quickly respond to the processing system. As a typical scenario, the control of a robotic arm in industrial control is a real-time service. The system needs to take timely measures before detecting a malfunction of the robotic arm; otherwise, it may cause serious consequences. The services assigned to the second operating system are usually non-real-time services. Non-real-time services refer to those that are not affected by the scheduling time, such as reading sensor data from a temperature sensor from a server, and have a certain tolerance for scheduling delays.

[0286] Note that 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, and the processing results can control the production process within a certain period of time or quickly respond to the processing system. It schedules all available resources for completing real-time services and controls all real-time services to be executed in a coordinated manner, and has characteristics such as timely response and high reliability.

[0287] After allocating each service to be allocated to the corresponding operating system, based on the service allocation result, processing resources corresponding to each service to be allocated can be allocated, and an allocation result of resources corresponding to a set of services to be allocated can be obtained. When allocating processing resources to a service to be allocated, the processing resources of the first operating system are 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, considering load balancing, if there are unallocated processing resources, some of the unallocated processing resources can be allocated to some services.

[0288] The processing resources of the processor can be dynamically allocated in time slice units, and the operating system to which the processing resources belong can be frequently switched. Considering that the service processing time is not necessarily an integer multiple of the time slice, and this may extend the response time of some services, it can be allocated to the first operating system and the second operating system in processor core units. That is, the processor cores of the processor are allocated to the corresponding operating system in units of the entire processor cores, 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] Based on the allocation results of the operating system and resources corresponding to each service to be allocated, the processing resources of the processor can be allocated to the first operating system and the second operating system. Optionally, the unallocated processing resources of the processor can be allocated to the corresponding operating system, and the unallocated processing resources can be determined based on the correspondence between the unallocated processing resources and the service to be allocated, and the correspondence between the service to be allocated and the operating system.

[0290] Optionally, allocating the processing resources of the processor to the first operating system and the second operating system can be performed by a resource automatic adaptation scheduling module (for example, a core automatic adaptation scheduling module). The resource automatic 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 automatic adaptation scheduling module can be realized by the software of the Linux system, and based on the output of the service management module and the output of the resource dynamic allocation module, the actual scheduling operation for the processing resources of the processor (for example, the hard core resources of the processor) can be completed. For example, after the resources are scheduled by the core resource automatic adaptation module, M 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, since different heterogeneous operating systems (heterogeneous operating systems) can be executed on different hard cores of the same processor, the entire processor system has the parallel processing function of real-time services and non-real-time services. At the same time, by automatically adapting and adjusting the hard core resources (such as processor cores) of the processor occupied by different operating systems, the utilization rate of the processor resources can be greatly improved. In this specification, heterogeneous means that the types of operating systems executed on the same multi-core processor of the embedded system are different, and multi-system means that the number of operating systems executed on the same multi-core processor of the embedded system is multiple, and those operating systems are executed 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 resource dynamic allocation rules. The resource dynamic allocation rules may be configured based on the rule configuration file. The read rule configuration file can be used to generate a rule structure for recording resource dynamic allocation rules. The rule configuration file may be a load balancing policy file (payload_balance.config), and the load balancing policy file can be used to configure classification methods for various services (or processes) during execution, and real-time level evaluation principles, etc. In the load balancing policy file, different parameters can be used to configure resource dynamic allocation rules. An example of the 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 importance and non-importance. Otherwise, it indicates that processes are classified according to a predetermined classification method (for example, real-time and non-real-time). real-time grade evaluation=2 / / If the value is 1, it indicates that the average CPU occupancy rate within the past statistical minutes is used as the evaluation principle for the real-time level of the process. Otherwise, it indicates that a predetermined 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 resource dynamic allocation rule can be stored in the load balancing policy module. In this specification, the load balancing policy module can be a software module executed in the first operating system or the second operating system (for example, a software module executed in a Linux system), and can provide policy guidance to the service management module, including the classification method of various services (or processes) executed in the system, the evaluation principle at the real-time level, etc. The service management module can divide and manage the services in the system according to the real-time level, and optionally, can guide the resource automatic adaptation scheduling module to reallocate the processor resources. Exemplarily, based on the output of the load balancing policy module, the actual classification of the services can be executed, and a list including real-time services and non-real-time services can be generated.

[0295] In addition, the above classification method and real-time level evaluation principle are open, allowing users to define specific methods or principles themselves, and enabling the rules for the service management module to perform service management to be dynamically configured. Therefore, selectable rules can be configured based on existing rules. The service management module can be configured with multiple rules having the same function, but there are no contradictions between the rules. That is, based on rule selection conditions such as the rule configuration time and rule priority, the currently used rule among memories with the same effect can be determined, thereby avoiding contradictions between rules. The above configuration file load_balance.config explains possible situations. In the configuration file, the classification_kinds variable indicates selectable classification criteria (such as service importance or real-time basis) and classification categories (such as important services and general services, real-time services and non-real-time services, etc.). The real-time_grade_evaluation variable indicates the evaluation criteria for real-time performance (which may be the average CPU occupancy rate within the past statistic_minutes minutes or a predetermined service priority). The type of real-time level may be defined by the user himself / herself and can be defined as three types: high, standard, and low, but it can also be further subdivided into more types.

[0296] The output of the load balancing policy module is the configured classification method, real-time level evaluation principle, etc. When realized by software, it may be a selectable configuration file (such as the load_balance.config file) or a structure variable. Since these files or structure variables can be finally accessed by the service management module, selectable policies for further load balancing can be obtained.

[0297] According to this embodiment, in order to record the resource dynamic allocation rules, generating a rule structure by reading a rule configuration file can improve the convenience of information configuration. Optionally, the above process is a step 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 using the rule update configuration file to update the rule update structure in order to update the resource dynamic allocation rules recorded in the rule update structure.

[0298] The rule structure may be in a fixed format, i.e., one that cannot be changed during the execution 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 is used to update the configured resource dynamic allocation rules, and the rule update structure can be updated using the rule update configuration file in order to update the resource dynamic allocation rules recorded in the rule update structure.

[0299] When updating the rule structure using the 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. Also, the parameter values of the corresponding rule parameters in the rule structure can be updated using the parameter values of the rule parameters indicated in the rule update configuration file.

[0300] Optionally, the configuration file in a specific format may be read by the external interfaces of the first operating system and the second operating system. Considering the amount of services to be processed, the resource dynamic scheduling of the embedded system, etc., can mainly be the responsibility of the second operating system. When obtaining the rule update configuration file, the rule update configuration file can be obtained via the external interface of the second operating system.

[0301] For example, the load distribution policy module may have a fixed format or may be configured by an external interface of the Linux system. For example, a file (load_balance.config) in the aforementioned specific format can be defined, and the configuration can be changed by the method of reading and writing the file. Note that the external interface is an external interface of a multi-core processor, and may be a network interface, an SPI (Serial Peripheral Interface) controller interface, a UART (Universal Asynchronous Receiver / Transmitter) serial port, etc., and it only needs to be able to acquire data from the outside. The hardware used for reading the file and the position of the file have different implementation means. For example, the configuration file can be loaded from a Web (World Wide Web) interface via a network interface, the configuration file can be read from the SPI Flash (flash memory) of the board via an SPI controller, and the configuration file can be obtained from a serial port data transmission and reception software tool in another PC (Personal Computer) via a UART serial port.

[0302] According to this embodiment, by obtaining a rule update configuration file and using it to update the rule structure, the flexibility of the structure of the resource dynamic allocation rule can be improved. Optionally, a set of services to be allocated can be allocated to the corresponding operating system in the embedded system by the following method based on the resource dynamic allocation rule, but not limited thereto. Among a set of services to be allocated, the service to be allocated with a response speed of the service higher than a threshold value of a predetermined response speed is allocated to the first operating system, and among a set of services to be allocated, the service to be allocated with a response speed of the service lower than a threshold value of a predetermined response speed is allocated to the second operating system.

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

[0304] For assignment target services whose service response speed requirements are equal to or higher than a predetermined response speed threshold, since they are affected by the operating system's scheduling time and response speed, such assignment target services can be assigned to the first operating system (for example, real-time services can be assigned to a real-time operating system). For assignment target services whose service response speed requirements are lower than the predetermined response speed threshold, since they are not affected by scheduling time and response speed, such assignment target services can be assigned to the second operating system (for example, non-real-time services can be assigned to a non-real-time operating system). In this specification, the service response speed requirements can be indicated by the service response speed indication parameter, and the predetermined response speed threshold can be a response speed threshold at the millisecond level such as 100 milliseconds or 200 milliseconds, or a response speed threshold at the second level such as 1 second. This embodiment does not limit the predetermined response speed threshold.

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

[0306] For example, divide the real-time level of the system's services, obtain a list of real-time services and non-real-time services. Assume that there are a total of 20 services, among which real-time services are Service 1 and Service 2, and non-real-time services are Service 3 to Service 20. In this specification, the service management module can classify the currently running services. When the BMC system is executed for the first time, since all the services currently running by the system are recognized by the system, 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) for execution. During subsequent execution, when the number of processes of a service changes (for example, when a certain process pauses or freezes, or a new process starts), the service management module can further continue to split the service and manage the 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 managing and splitting the currently running processes.

[0307] According to this embodiment, by assigning the target service to be assigned to the corresponding operating system according to the requirements of the response speed of the service, the rapidity of the response to the service affected by the scheduling time can be ensured. Optionally, a set of target services to be assigned can be assigned to the corresponding operating system in the embedded system by the following method based on the resource dynamic allocation rule, but not limited thereto. Among a set of target services to be assigned, the target service with a resource occupancy rate smaller than the threshold of the first occupancy rate is assigned to the first operating system, and among a set of target services to be assigned, the target service with a resource occupancy rate equal to or higher than the threshold of the first occupancy rate is assigned to the second operating system.

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

[0309] For a service to be allocated whose resource occupancy rate is less than the threshold of the first occupancy rate, the impact on the scheduling time and response speed of the operating system is reduced, and such a service to be allocated can be allocated to the first operating system. For a service to be allocated whose resource occupancy rate is equal to or higher than the threshold of the first occupancy rate, the impact on the scheduling time and response speed of the operating system is increased, and such a service to be allocated can be allocated to the second operating system. In this specification, the first occupancy rate can be selectively set and may be 10%, 15%, 20% or other thresholds. At the same time, the threshold of the first occupancy rate can be dynamically adjusted.

[0310] According to this embodiment, by allocating the service to be allocated to the corresponding operating system according to the resource occupancy rate of the service, the rapidity of the response to the service with a low resource occupancy rate can be ensured. Optionally, a set of services to be allocated can be, but is not limited to, allocated to the corresponding operating system in the embedded system by at least one of the following methods based on the resource dynamic allocation rule.

[0311] Allocate the service to be allocated with a degree of association with the already allocated services of the first operating system among the set of services to be allocated to the first operating system if the degree of association is equal to or higher than the threshold of the first degree of association. Allocate the service to be allocated with a degree of association with the already allocated services of the second operating system among the set of services to be allocated to the second operating system if the degree of association is equal to or higher than the threshold of the second degree of association.

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

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

[0314] For a set of target services to be allocated, if there is a target service to be allocated whose coupling degree with the already allocated service of the first operating system is equal to or higher than the threshold of the first coupling degree, such a target service to be allocated can be allocated to the first operating system. For a set of target services to be allocated, if there is a target service to be allocated whose coupling degree with the already allocated service of the second operating system is equal to or higher than the threshold of the first coupling degree, such a target service to be allocated can be allocated 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 further responsible for the separate evaluation and management of services, that is, in order for the hardware resource dynamic allocation module to reallocate processor resources, it finds services that can be independently executed by the real-time operating system from all real-time services, and for services that cannot be independently executed by the real-time operating system, if the degree of coupling with non-real-time services is high, such services 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 (that is, the degree of coupling of the services is high). In this case, in order to improve the efficiency of the overall data interaction, such services are allocated to the non-real-time operating system. Another type of real-time service is relatively independent itself. In this case, it only needs to be split into the real-time operating system, and this process is called the "separation" operation. The criterion for judging the independence of services may not be the only one, but may be the tightness of the relationship between the above-mentioned services, or other indicators that users are concerned about.

[0317] The reallocation policy is open, and one of the feasible policies is as follows. When the system starts running for the first time, 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 execution, the resource allocation is adjusted based on the core resource occupancy rate of each of the dual systems. From that perspective, the reallocation process and the core preemption and release processes are processes that cooperate with each other.

[0318] According to this embodiment, by allocating the service to be allocated to the corresponding operating system according to the degree of coupling of the service, the accuracy of processing for a plurality of services with a high degree of coupling can be ensured. Optionally, a set of services to be allocated can be allocated to the corresponding operating system in the embedded system by the following method based on the resource dynamic allocation rule, but not limited thereto.

[0319] Allocate the service to be allocated including confidential information among a set of services to be allocated to the target operating system, and the target operating system is the operating system with a low interaction frequency with the user among the first operating system and the second operating system. In this embodiment, in the case of a service to be allocated including confidential data (for example, confidential information such as a password), which may be an important and highly confidential service, for example, a service that is not intended to be made public to users, it is allocated to the target operating system, and the target operating system may perform security protection separation at the hard core level for the service to be allocated including confidential information. In this specification, the target operating system is the operating system with a low interaction frequency with the user among the first operating system and the second operating system, or the operating system with a high response speed such as the first operating system.

[0320] For example, the service processing module selectively performs security protection separation at the hardware core level on the service system, that is, divides important and highly confidential (services that should not be made public to users) services into real-time services, and finally realizes the offloading of these services from the non-real-time operating system to the real-time operating system, achieving the effect of security protection. In this specification, different services divided by the service processing module can be organized in the form of a structure in the case of software implementation. By designing the security space between heterogeneous operating systems, confidential services are offloaded from the non-real-time operating system to the real-time operating system, achieving the purpose of security protection at the hardware core level. In this specification, confidential services refer to security-related services such as user passwords and identity information, as well as other services related to user privacy.

[0321] In this specification, "hardware core" means that services are separated at the processor core level, that is, confidential services are 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, it belongs to the separation at the core level). Compared with the non-real-time operating system, the real-time operating system has a lower frequency and degree of interaction with users, so it is difficult for users as users to "detect" confidential data generated by the services they execute on it. In the case of upper-level applications, services such as user identity authentication management and security encryption belong to the above-mentioned important confidential services. Since the service management module forcibly divides the above services into real-time services, when performing subsequent dynamic allocation of hardware resources, the above services can be realized to be executed in the real-time operating system, thereby achieving the effect of security separation.

[0322] According to this embodiment, by allocating the service to be allocated including confidential information to an operating system with a low frequency of interaction with the user, the services of the system can be separated by security protection at the hard core level, and the security of service execution can be improved. Optionally, the allocation result of the resources corresponding to a set of services to be allocated can be determined by, but not limited to, the following method.

[0323] Based on the allocation result of a set of services to be allocated, combine 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, and generate a mapping table between the service to be allocated and the processing resources of the processor.

[0324] In this embodiment, the allocation result of a set of allocated services is used to indicate the correspondence between the service to be allocated and the operating system. The service to be executed allocated to the operating system is usually executed by the processing resources of the operating system. If the amount of services allocated to a certain operating system is too large and there are currently unallocated processing resources, the unallocated processing resources can also be allocated to the service to be allocated allocated to a certain operating system. Therefore, based on the allocation result of a set of services to be allocated, combine 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, and a mapping table between the service to be allocated and the processing resources of the processor can be generated to indicate the processing resources allocated to each service to be allocated.

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

[0326] For example, based on the output result of the service management module, the resource dynamic allocation module dynamically adjusts the processor resources, forms a mapping table between different services and the 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 the overall system hardware resources. The above resource dynamic allocation process can be managed and arranged by the software in the second operating system.

[0327] Taking an 8-core processor (cores 1 to 8) as an example, the processor cores scheduled by the first operating system include core 1, the processor cores scheduled by the second operating system include cores 2, 3, and 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 services 3 to 6. Corresponding processor cores are assigned to the six services. Core 1 is assigned to service 1, core 5 is assigned to service 2, core 2 is assigned to service 3, core 3 is assigned to service 4, core 4 is assigned to service 5, and core 6 is assigned to service 6.

[0328] According to this embodiment, based on the correspondence relationship between the service and the operating system, the usage status of the processing resources of different operating systems is combined, and the processing resources are dynamically allocated, so that the rationality of the allocation of the processing resources can be ensured. Optionally, the processing resources of the processor can be allocated to the first operating system and the second operating system in the following manner based on the operating system corresponding to each service to be allocated and the allocation result of the resources, but not limited thereto. Based on the allocation result of the resources, for the unallocated processing resources among the processing resources of the processor, if there is a corresponding service to be allocated, the unallocated processing resources are allocated to the operating system to which the service to be allocated corresponding to the unallocated processing resources is allocated.

[0329] When allocating the processing resources, for the unallocated processing resources among the processing resources of the processor, if there is a corresponding service to be allocated, that is, when allocating the unallocated processing resources to the service to be allocated, the unallocated processing resources can be allocated to the operating system to which the service to be allocated corresponding to the unallocated processing resources is allocated.

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

[0331] Taking the aforementioned 8-core processor as an example, based on the service allocation result and the 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, in order to schedule the unallocated processing resources to the corresponding operating system based on the resource allocation result, the utilization rate of the processor resources can be improved.

[0332] It can be controlled that the first operating system enters the sleep state after execution. For example, it is controlled that the first operating system sleeps after execution. The end of the execution of the first operating system may be the end of the execution cycle, or the completion of the processing of the wake-up request, or the completion of the processing of the current operating service. After the first operating system sleeps, the second operating system can occupy the processor core allocated to the first operating system, so as to improve the resource utilization rate. For example, after controlling that the first operating system sleeps after execution, the second operating system is notified to be allowed to occupy the processor core used by the first operating system, and the second operating system is used to add the target processor core used by the first operating system into the scheduling resource pool of the second operating system during the sleep period of the first operating system. The scheduling resource pool includes other processors in the processor except the target processor core.

[0333] Optionally, in this embodiment, the method of notifying the second operating system to allow it to occupy the processor core used by the first operating system may include, but is not limited to, the method of sending an interrupt request to the second operating system. After the first operating system goes to sleep, send an interrupt request to the second operating system to notify it that it is allowed to use the processor core used by the first operating system. In response to the interrupt request, the second operating system adds the target processor core used by the first operating system to the scheduling resource pool for scheduling and use.

[0334] In an exemplary embodiment, it is possible to monitor the operating services running in the second operating system, but not limited thereto. When monitoring an abnormal operating service, the first operating system can take over the execution of the abnormal operating service, thus avoiding the abnormal execution of the operating service from affecting the entire process of processing and improving the execution success rate and efficiency of the service. For example, when monitoring the operating services running in the second operating system and detecting that there is an abnormal operating service among the operating services running in the second operating system, the first operating system takes over the abnormal operating service.

[0335] Optionally, in this embodiment, the second operating system can be monitored by a processor or a first operating system, but it is not limited thereto. The monitored abnormal operating service (for example, an operating service in which a service thread pauses or freezes) is taken over by the first operating system. Alternatively, in order to take over, the monitored abnormal operating service can be assigned to an operating system in the multi-operating system that has a high degree of compatibility with the abnormal operating service.

[0336] Optionally, in this embodiment, the method of monitoring the operating service executed in the second operating system may include, but is not limited to, monitoring a heartbeat signal and monitoring a service log. For example, when it is monitored that an abnormal log is generated, it is determined that the operating service is abnormal. In an exemplary embodiment, the operating service executed in the second operating system can be monitored in the following manner, but is not limited thereto. Receive the heartbeat signal of each operating service executed in the second operating system, and determine an operating service whose heartbeat signal frequency does not match the corresponding target frequency as an abnormal operating service.

[0337] Optionally, in this embodiment, each operating service executed in the second operating system generates a heartbeat signal, and the heartbeat signals of different operating services have different frequencies. Connect the heartbeat signal of each operating service executed in the second operating system 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 takes over an operating service whose heartbeat signal frequency does not match the corresponding target frequency as an abnormal operating service.

[0338] Optionally, in this embodiment, whether the frequency of the heartbeat signal matches the corresponding target frequency can be determined by comparing whether the two completely match, but it is not limited thereto. If they completely match, it is determined that they match; if they do not completely match, it is determined that they do not match. Alternatively, a certain error range can be given, but it is not limited thereto. Whether they match is determined by comparing whether the frequency of the heartbeat signal is within the error range of the target frequency. If it is within the error range, it is determined that they match; 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 inherits an abnormal operating service, the abnormal operating service in the second operating system can be restarted in the following manner, but it is not limited thereto. A restart command is sent to the second operating system, and the restart command is used to indicate restarting the abnormal operating service.

[0340] Optionally, in this embodiment, the restart command is used to indicate restarting the abnormal operating service. 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 stores the current execution context of the abnormal operating service in the shared memory and can send an interrupt request to the second operating system. The second operating system reads the current execution context of the abnormal operating service from the shared memory and loads it into the abnormal operating service that is executed thereon. Finally, the abnormal operating service can continue to execute, and the execution efficiency of the service is also improved.

[0341] FIG. 10 is a schematic diagram of the monitoring process of system anomalies according to an embodiment of the present application. As shown in FIG. 10, the first operating system executes the heartbeat signal of the operating service running on the second operating system, detects an abnormal operating service whose heartbeat signal frequency does not match the target frequency, and the first operating system takes over and continues to execute the abnormal operating service in the second operating system. In order for the second operating system to restart the abnormal operating service, the first operating system sends a restart command to the second operating system.

[0342] In an exemplary embodiment, the dual system can be started in the following manner, but is not limited thereto. Boot so that the first operating system starts, and boot so that the second operating system starts. Optionally, in this embodiment, first, boot so that the first operating system starts, and then, boot so that the second operating system starts. 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 with high urgency or an operating service that helps the startup of the second operating system, and finally, the startup efficiency of the operating system can be improved, or the processing efficiency of the operating service can be improved.

[0343] Optionally, in this embodiment, the first operating system and the second operating system can be started in sequence, but not limited thereto. The first operating system can be started faster than the second operating system, but not limited thereto. The first operating system can be simpler than the conditions required for the second operating system to start, but not limited thereto. After the first operating system starts first, services that meet the conditions required for the second operating system to start can be executed, or the services for starting the second operating system can be accelerated. Finally, the multi-system can start and execute services efficiently and quickly.

[0344] For example, after booting to start the first operating system, services (such as fan execution, parameter control, etc.) are executed by the first operating system to control the chip's environmental parameters to meet the startup requirements of the second operating system. Finally, the chip's environmental parameters can quickly realize the environment required for the startup and execution of the second operating system, and the startup efficiency and execution efficiency of the operating system can be improved.

[0345] Optionally, in this embodiment, the startup of the first operating system can be booted by the boot program of the first operating system, but not limited thereto. The startup of the second operating system can be booted by the boot program of the second operating system, but not limited thereto. Or, both can be started in sequence by the same bootloader program.

[0346] In an exemplary embodiment, the startup of the first operating system can be booted in the following manner, but is not limited thereto. The chip is powered on and started, and the processor wakes up the first processor core assigned to the first operating system. The first processor core executes the boot program of the first operating system, and boots so that the first operating system is started.

[0347] Optionally, in this embodiment, the first processor core of the first operating system can be determined based on the processor core in the processor where the first operating system is located, but is not limited thereto. For example, the processor where the first operating system is located may include a plurality of processor cores (processor core 0 to processor core N), but is not limited thereto. One or more of the plurality of processor cores (for example, processor core 0) can be assigned as the first processor core of the first operating system to the first operating system, but is not limited thereto.

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

[0349] In an exemplary embodiment, the first processor core can execute the boot program of the first operating system in the following manner to boot the first operating system, but is not limited thereto. The first processor core can execute a two-stage program loader, and 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 a two-stage program loader, but is not limited thereto. The first processor core can load the first operating system by executing a two-stage program loader (Second Program Loader, SPL), but is not limited thereto.

[0350] In an exemplary embodiment, the startup of the second operating system can be booted in the following manner, but is not limited thereto. The two-stage program loader wakes up the 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 so that it starts up.

[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 where the second operating system is located, but is not limited thereto. For example, the processor where the second operating system is located may include a plurality of processor cores (processor core 0 to processor core N), but is not limited thereto. One or more of the plurality of processor cores (for example, processor core 1 to processor core N) can be assigned as the second processor core of the second operating system to the second operating system, but is not limited thereto.

[0352] Optionally, in this embodiment, the two-stage program loader can wake up the second processor core of the second operating system, but is not limited thereto. For example, after the two-stage program loader completes the loading of the first operating system, the two-stage program loader can wake up the second processor core of the second operating system, but is not limited thereto. Or, in the process of loading the first operating system using the two-stage program loader, the two-stage program loader can wake up the second processor core of the second operating system, but is not limited thereto.

[0353] Optionally, in this embodiment, the second processor core can boot by executing the boot program of the second operating system to start the second operating system, but is not limited thereto. In an exemplary embodiment, the second operating system can be booted by executing the boot program of the second operating system on the second processor core in the following manner, but is not limited thereto. The second processor core executes a general-purpose boot loader, and the boot program of the second operating system includes the general-purpose boot loader, and the general-purpose boot loader loads the second operating system.

[0354] Optionally, in this embodiment, the second processor core can execute a general-purpose boot loader to load the second operating system, but is not limited thereto. The general-purpose boot loader may include U-Boot (Universal Boot Loader), but is not limited thereto. In an exemplary embodiment, the two-stage program loader can be executed on the first processor core in the following manner, but is not limited thereto. The boot storage device in the chip performs a clean boot inspection on the code of the two-stage program loader. If the inspection 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 a two-stage program loader, but is not limited thereto. The boot program of the operating system can be used as the above-mentioned boot storage device, and the code of the two-stage program loader included in the boot program of the operating system can be verified by the boot storage device, but is not limited thereto. For example, based on the boot program of the first operating system (the boot program may be a BootROM, but is not limited thereto), the two-stage program loader of the first operating system (the two-stage program loader may be an SPL, but is not limited thereto) can be obtained, but is not limited thereto. Based on the boot storage device of the first operating system (the boot storage device may be a BootROM, but is not limited thereto), the code of the two-stage program loader can be verified, but is not limited thereto.

[0356] Optionally, in this embodiment, the process of the boot storage device performing a clean boot inspection on the code of the two-stage program loader is that the boot storage device reads the code and identification code of the two-stage program loader, calculates the code of the two-stage program loader by a predetermined calculation method (for example, hash calculation), obtains a calculated value, and then compares the calculated value with the read identification code. If the two are the same, the inspection result is normal; if the two are different, the inspection result is abnormal, but is not limited thereto.

[0357] Optionally, in this embodiment, the two-stage program loader can perform a clean boot inspection on the code of the general-purpose bootloader. The two-stage program loader reads the code and identification code of the general-purpose bootloader, and calculates the code of the general-purpose bootloader by a predetermined calculation method (for example, hash calculation, which may be the same as or different from the calculation method by which the above-mentioned boot storage device inspects the two-stage program loader), to obtain a calculated value. Next, the calculated value is compared with the read identification code. If the two match, the inspection result is normal; if they do not match, the inspection result is abnormal. When the inspection result is normal, the general-purpose bootloader loads the second operating system.

[0358] According to an exemplary embodiment, examples of the first operating system and the second operating system are provided. Taking the first processor core as CPU-0 and the second processor cores 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 thereto. The chip is powered on and started, 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. It may be a two-stage program loader, but not limited thereto. A clean boot inspection is performed on the code of the two-stage program loader for the boot storage device (which may be BootROM, but not limited thereto) in the chip. When the inspection result is normal, the first processor core executes the two-stage program loader (which may be SPL, but not limited thereto) to load the first operating system. The two-stage program loader wakes up the second processor cores CPU-1 to CPU-N of the second operating system, and the second processor cores use the general-purpose bootloader (which may be U-Boot, but not limited thereto) to load the second operating system.

[0359] According to the description of the above embodiments, those skilled in the art can clearly understand that based on the methods of the above embodiments, it can be implemented by software and the necessary general-purpose hardware platform, and of course also by hardware. However, in many cases, the former is a more preferred embodiment. Based on such an 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. The computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk), and includes a plurality of instructions for causing a terminal device (which may be a mobile phone, computer, server, or 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 operating system execution control method. FIG. 11 is a schematic diagram 1 of the 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 includes 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 that 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. At least two operating systems are executed based on the processor 1102. At least two operating systems communicate via the first bus 1106, and at least two operating systems realize control to the hardware controller via the second bus 1108.

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

[0362] The embedded system may include at least two operating systems. The at least two operating systems are executed based on a processor, and the resources of the processor are dynamically allocated to the at least two operating systems. The processing resources of the processor include processor cores. The at least two operating systems communicate via the first bus, and the at least two operating systems realize control to the hardware controller via the second bus.

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

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

[0365] The above cores and each controller are interconnected via a second bus to realize the interaction between the cores and each controller. At the same time, the ARM core is connected to the first bus (for example, connected by an AXI (Advanced eXtensible Interface) bridge), and the communication between the cores is realized by the first bus. In addition, the SOC sub-module further realizes the interconnection and intercommunication between the first bus and the second bus (for example, realized by the conversion of a bridge), so as to provide a physical channel for the SOC sub-module 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. 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 external devices of the chip such as PWM, GPIO, FanTech (adjustment of fan rotation speed), mailbox, etc. Through these controllers, out-of-band management functions such as PECI communication to the BMC (for example, simulating PECI using GPIO) and fan adjustment control can be realized. As can be seen from Figure 12, the BMC out-of-band sub-module can realize interaction with the SOC sub-module via the second bus, but is not limited thereto.

[0368] The MC chip realizes the interconnection among the on-chip ARM core, memory unit, and controller hardware resources via the first bus and the second bus. Processor resource dynamic balancing scheduling mainly concerns the scheduling of the ARM core resources of the BMC chip, and the communication between cores refers to the communication between ARM cores. Taking the example of the Linux system preempting the RTOS system core, first, on a certain core among cores 2 to N, the Linux system sends an inter-core interrupt (interrupt number 9) to core 1 through the on-chip bus. In this case, when the RTOS system is in the idle state, preemption is permitted, and core 1 recovers the inter-core interrupt (interrupt number 10) through the first bus, and then releases the controller resources of the external device mapped on the current core 1 (for example, PWM / PECI). The Linux system receives the inter-core interrupt 10, starts the preemption process, adds core 1 to the Linux SMP scheduling, and at the same time, can obtain the control process of the PWM / PECI external device and control it through the second bus.

[0369] On the one hand, there are at least two operating systems, including the first operating system and the second operating system. The chip loads a communication value onto the first bus, and the first bus sends a communication signal containing the communication value to the corresponding communication register of the second operating system, realizing the communication between the first operating system and the second operating system. The communication value is used to indicate the content of the communication between the first operating system and the second operating system.

[0370] On the other hand, the chip loads a control value onto the second bus, and the second bus sends a control signal containing the control value to the corresponding register of the hardware controller, realizing the control of the hardware controller by the operating system. 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 operations and write operations). The way the operating system accesses the registers of each hardware controller may be by reading or writing to the addresses of the registers of each hardware controller, but is not limited thereto. The addresses of these registers can be uniquely determined during chip design, but are not limited thereto. For example, the operating system can realize a specific function (e.g., the communication function between the above operating systems or the control function of the operating system for the hardware controller) by simply writing a specific value (i.e., the above communication value or control value) to a specific address (i.e., the above communication register or the register corresponding to the hardware controller). That is, different functions correspond to different control values. In the chip, the correspondence between the functions of the hardware controller and the control values is maintained. For example, the control value 00 indicates that the air conditioner accelerates at the first speed, and the control value 01 indicates that the air conditioner decelerates at the first speed.

[0372] Interactions such as communication and control can be performed between each operating system and between the operating system and the hardware controller via a bus, but are not limited thereto. The read and write operations of the above operating system to the registers of each hardware controller can finally be converted by the first bus (or the second bus) into a control signal to the hardware controller. This conversion operation and the control process of the first bus (or the second bus) to the hardware controller can be automatically realized by the hardware inside the chip, but are not limited thereto. The realization process follows the rules of the bus. Here, in the operating process of the first bus (or the second bus), physical signals related to the bus protocol can be transmitted and controlled, while valid data can be transmitted 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. For the multi-master / multi-slave mode of the first bus, the master first sends a transmission request to the arbiter. The arbiter determines when to grant the master access to the bus. After the master obtains permission, it sends data and control signals to the arbiter. The arbiter analyzes and determines the corresponding slave channel based on the 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 enables many-to-many access.

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

[0375] In the above embedded system configured such that the first bus is in multi-master / multi-slave mode and the second bus is in single-master / multi-slave mode, the first bus in multi-master / multi-slave mode can complete communication between systems more efficiently by using a more complex logic circuit and bus protocol. The second bus in single-master / multi-slave mode uses a simpler logic circuit and bus protocol to complete the control of the system to the hardware controller while reducing the complexity of the structure and the power consumption of the entire embedded system. The arrangement and cooperation of multiple modes of the bus can further improve the execution performance of the embedded system.

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

[0377] In an exemplary embodiment, 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 a processor. When the target operating service is executed up to a target service state, the first operating system releases the target hardware controller via the second bus. 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 service is executed by the target hardware controller, and the first operating system controls the target hardware controller based on the processor. The second operating system inherits the target operating service by inheriting the target hardware controller.

[0379] Optionally, in this embodiment, the process of inheriting the target operating service is the same as that in the foregoing embodiment, so the description is omitted here. When the target operating service runs to 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 to the register of the target hardware controller in order to achieve the purpose of disabling the target hardware controller. The above specific value that needs to be written is automatically loaded by the chip hardware into the data channel of the second bus, and finally, the control of the hardware controller is realized in a hardware manner (i.e., the release operation is realized).

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

[0381] In an exemplary embodiment, the second operating system sends a first interrupt request to the first operating system via a first bus, and the first interrupt request is used to request to inherit a target hardware controller. The first operating system responds to the first interrupt request and releases the target hardware controller via a second bus, or the first operating system releases the target hardware controller via the second bus when the service attribute of the target operating service reaches the target service attribute.

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

[0383] Optionally, in this embodiment, the process of releasing and inheriting the target hardware controller is the same as that in the foregoing embodiment, so the description is omitted here. To implement the second operating system sending a first interrupt request to the first operating system, the second operating system writes a specific value (i.e., the above communication value) corresponding to the first interrupt request into an interrupt register. The above specific value that needs to be written is automatically loaded by the chip hardware into the data channel of the first bus, and finally, the function of the interrupt request is implemented in a hardware manner.

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

[0385] Optionally, in this embodiment, the first operating system can determine whether the second operating system inherits the target hardware controller. Since the determination process is the same as that in the foregoing embodiments, the description is omitted here. In an exemplary embodiment, when the second operating system does not inherit the target hardware controller, the first operating system sends a second interrupt request to the second operating system via the first bus. The second interrupt request is used to indicate that the second operating system is rejected from inheriting the target hardware controller.

[0386] Optionally, in this embodiment, the process by which the first operating system rejects the second operating system from inheriting the target hardware controller is the same as that in the foregoing embodiments, so the description is 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. The second operating system responds to the third interrupt request and controls the target hardware controller to execute the target operating service via the second bus.

[0387] Optionally, in this embodiment, the process by which the first operating system communicates to the second operating system that the target hardware controller has already been released is the same as that in the foregoing embodiments, so the description is omitted here. To achieve the goal that the target hardware controller executes the target operating service, the second operating system writes a specific value (i.e., the above control value) corresponding to the target operating service into the register of the target hardware controller. The specific value that needs to be written is automatically loaded by the chip hardware into the data channel of the second bus, and finally, the control to the hardware controller is realized in a hardware manner.

[0388] In an exemplary embodiment, at least two operating systems include a first operating system and a second operating system. The first operating system is executed based on a target processor core in a processor. When the first operating system executes up to the target system state, it releases the target processor core. The second operating system adds the target processor core into the scheduling resource pool of the second operating system. The scheduling resource pool includes processor cores in the processors assigned to the second operating system.

[0389] Optionally, in this embodiment, the process in which at least two operating systems occupy the target processor core is the same as that in the previous embodiment, so the description is 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. 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 the system attribute reaches the target system attribute.

[0390] Optionally, in this embodiment, the second operating system can actively preempt the target processor core, and the first operating system can also actively release the target processor core. Optionally, in this embodiment, the process of preempting and releasing the target processor core is the same as that in the foregoing embodiment, so the description is omitted here.

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

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

[0393] Optionally, in this embodiment, the process by which the first operating system refuses the second operating system to occupy the target processor core is the same as that in the foregoing embodiment, so the description is omitted here. In an exemplary embodiment, the first operating system sends a sixth interrupt request to the second operating system, and the sixth interrupt request is used to indicate that the first operating system has already released the target processor core. In response to the sixth interrupt request, the second operating system adds the target processor core into the scheduling resource pool.

[0394] Optionally, in this embodiment, the process by which the first operating system communicates to the second operating system that the target processor core has already been released is the same as that in the previous embodiment, and thus the description is omitted here. In an exemplary embodiment, at least two operating systems include a first operating system and a second operating system. The target processor core in the processor is added into the scheduling resource pool of the second operating system. The scheduling resource pool includes the processor cores in the processors assigned to the second operating system. When the first operating system is woken up, the second operating system releases the target processor core, and the first operating system is executed 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 that in the previous embodiment, and thus the description is omitted here. In an exemplary embodiment, when the first operating system is woken up, the second operating system either releases the target processor core or sends a seventh interrupt request to the second operating system. The seventh interrupt request is used to request the second operating system to release the target processor core. In response to the seventh interrupt request, the second operating system releases the target processor core.

[0396] Optionally, in this embodiment, when the first operating system is woken up, the second operating system actively releases the target processor core, or the first operating system actively requests that the second operating system release the target processor core. Since this process is the same as that in the foregoing embodiment, the description is omitted here.

[0397] In an exemplary embodiment, at least two operating systems include a first operating system and a second operating system. The chip further includes a memory space. At least two operating systems control the memory space via a first bus. In the process where the first operating system is executed based on a processor, service data is generated. The first operating system stores the service data in the memory space via the first bus, and then sends an eighth interrupt request to the second operating system via the first bus. The eighth interrupt request is used to request that the second operating system read the service data from the memory space. 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 the interaction of data between systems by transmitting the memory space and interrupt requests, but are not limited thereto. Since the process of data interaction between systems is the same as that in the foregoing embodiment, the description is omitted here. To achieve the purpose of storing service data in the memory space, the first operating system writes a specific value to a specific address of the memory controller. 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 of the memory controller and the storage of service data are realized in a hardware manner (that is, the transmission of valid data is realized through its physical data channel).

[0399] In an exemplary embodiment, the first operating system is executed periodically based on a processor, or in response to a received wake-up request and executed based on the processor, or executed based on the processor according to the compatibility between the operating services generated by the processor and the first operating system. Optionally, in this embodiment, since the execution mechanism of the first operating system is the same as that in the foregoing embodiment, the description thereof is omitted here.

[0400] In an exemplary embodiment, after the first operating system is executed and then enters the sleep state, the second operating system adds the target processor core used by the first operating system during the sleep period of the first operating system into the scheduling resource pool of the second operating system, and the scheduling resource pool includes other processors in the processor except the target processor core.

[0401] Optionally, in this embodiment, the process by which the second operating system rejects occupying the target processor core during the sleep period of the first operating system is the same as that in the foregoing embodiment, so the description thereof is omitted here. In an exemplary embodiment, at least two operating systems communicate through a communication protocol arranged by the first bus, or at least two operating systems communicate through the first bus, the second bus, and the communication hardware controller in the hardware controller.

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

[0403] In an exemplary embodiment, at least two operating systems communicate by sending an interrupt request between processors via a first bus, or one of the at least two operating systems sends a system interrupt request to the first bus, and 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 a 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.

[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 an interrupt between cores, but are not limited thereto. For example, it is SGI (Software Generated Interrupt, an interrupt generated by software, an interrupt between cores in a Linux system). To require preemption or release of processing resources, one operating system sends a resource preemption request (for example, a core preemption request) or a resource release request (for example, a core release request) to another operating system by IPI (Inter-Processor Interrupt, an interrupt between processors).

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

[0406] Optionally, in this embodiment, the process by which the first operating system monitors the abnormal operating services in the second operating system is the same as that in the foregoing embodiments, so the description is omitted here. Each operating service of the second operating system writes a value to a specific address of the memory controller at a certain frequency. To achieve the purpose of monitoring the operating system executed by the second operating system, the first operating system reads the specific address of the memory controller. The specific address of the memory controller that needs to be read is automatically loaded into the address channel of the first bus by the chip hardware, and the specific address of the memory controller is read in a hardware manner. The read value is returned to the first operating system in a hardware manner from the data channel of the first bus, and finally, the monitoring of the operating services executed by the second operating system is realized.

[0407] It is also possible that the first operating system takes over the abnormal operating service, which is control over the hardware controller corresponding to the abnormal operating service. To control the hardware controller, the first operating system writes a specific value to the register of the hardware controller of the abnormal operating service. The specific value that needs to be written is automatically loaded by the chip hardware into the data channel of the first bus, and finally, control over the hardware controller and inheritance of the abnormal service are realized in a hardware manner.

[0408] In an exemplary embodiment, the first operating system receives the heartbeat signal of the operating service executed by the second operating system via the first bus, and the first operating system takes over, as an abnormal operating service, the operating service whose heartbeat signal frequency does not match the corresponding target frequency via the first bus.

[0409] Optionally, in this embodiment, the process by which the first operating system monitors the abnormal operating service in the second operating system by monitoring the frequency of the heartbeat signal is the same as that in the foregoing embodiment, and thus the description thereof is omitted here. To achieve the purpose of receiving the heartbeat signal of the operating service executed by the second operating system, the first operating system reads the value at a specific address of the memory controller. The specific address of the memory controller that needs to be read is automatically loaded by the chip hardware into the address channel of the first bus, and reading of the specific address of the memory controller is realized in a hardware manner. The read value is returned from the data channel of the first bus to the first operating system in a hardware manner, and finally, reception of the heartbeat signal of the operating service executed by the second operating system is realized.

[0410] In an exemplary embodiment, after the first operating system inherits an 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 restarting the abnormal operating service.

[0411] Optionally, in this embodiment, since the process of restarting the abnormal operating service after the first operating system inherits the abnormal operating service in the second operating system is the same as that in the foregoing embodiment, the description thereof is omitted here. After the first operating system inherits the abnormal operating service, in order to achieve the purpose of restarting the abnormal operating service in the second operating system, it writes a specific value to a specific address of the memory controller. The specific value that needs to be written is automatically loaded into the data channel of the first bus by the chip hardware, and the update of the value of the specific address of the memory controller is realized in a hardware manner. The second operating system reads and analyzes the above specific value, and further restarts the corresponding abnormal operating service.

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

[0413] Optionally, in this embodiment, since the startup boot process of the multi-operating system is the same as that in the foregoing embodiment, the description thereof is omitted here. In an exemplary embodiment, at least two operating systems include a first operating system and a second operating system. The first operating system controls, based on a processor, a target hardware controller to execute a target operating service. When the target operating service is executed to a target service state, the first operating system releases the target hardware controller via a second bus. The second operating system controls, via the second bus, the target hardware controller to execute the target operating service. The first operating system is executed based on a target processor core in the processor. When the first operating system is executed to a target system state, the first operating system releases the target processor core. The second operating system adds the target processor core into a scheduling resource pool of the second operating system. The scheduling resource pool includes processor cores allocated 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. In the process of the first operating system being executed based on the processor, service data is generated. 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. The second operating system reads the service data from the storage space in response to the eighth interrupt request.

[0414] Optionally, in this embodiment, not only can the operating systems inherit the hardware controller, but also can preempt the processor core. Since the process is the same as that of the foregoing embodiment, the description is omitted here. According to this embodiment, there is further provided an embedded system configured to implement the above method for controlling the execution of an operating system. The above embedded system can be executed on the above BMC chip. The embedded system includes a first operating system, a second operating system, a controller, and a processor. The first operating system and the second operating system are executed based on the processor. 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 embedded system, the first operating system and the second operating system are executed based on the processor. The controller detects the execution state of the first operating system during the execution process and controls the processor resources used by the first operating system based on the execution state. Since both the first operating system and the second operating system are executed based on the same processor, an increase and arrangement of hardware are avoided, the system cost is reduced, and during the execution process of the operating system, the used processor resources can be controlled, and the execution between systems can be assisted by rationally using the processor resources. Thereby, the technical problem of low execution efficiency of the operating system can be solved, and the technical effect of improving the execution efficiency of the operating system can be achieved.

[0416] In this embodiment, the first operating system and the second operating system may be the same as those in the foregoing embodiment. The first operating system and the second operating system can be executed by the processor, and the controller may be software executed by the first operating system or the second operating system.

[0417] Optionally, in this embodiment, the processing logic of the controller may be disposed in the processor, but is not limited thereto. Further, it may be disposed in the first operating system, or may be divided into a first control unit and a second unit respectively disposed in the first operating system and the second operating system according to functions, but is not limited thereto. Ultimately, it realizes control of processor resources between systems, management of operating services, and interaction of services, etc.

[0418] In an exemplary embodiment, the controller detects the service state of the target operating service of the first operating system executed based on the processor, the execution state includes the service state, detects the system state of the first operating system, the execution state includes the system state, and the first operating system is configured as at least one of the configurations executed based on the target processor core in the processor.

[0419] Optionally, in this embodiment, since the detection of the service state and the system state by the controller is the same as that in the foregoing embodiment, the description is omitted here. In an exemplary embodiment, when the controller detects that the service state is the target service state, it is configured to release the target operating service, the processor resources include the target operating service, the second operating system is used to execute the target operating service, and / or when the controller detects that the system state is the target system state, it is configured to release the target processor core, the processor resources include the target processor core, and the second operating system is used to add the target processor core into the scheduling resource pool of the second operating system, and the scheduling resource pool includes the processor cores in the processor assigned to the second operating system.

[0420] Optionally, in this embodiment, the process by which the controller controls the target operating service and the process of releasing the target processor core are the same as those in the foregoing embodiments, and thus the description thereof is omitted here. In an exemplary embodiment, the embedded system further include...

Claims

1. An embedded system including a chip and at least two operating systems, wherein 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 as a multi-master / multi-slave mode, and the second bus is configured as a single-master / multi-slave mode, the at least two operating systems are executed based on the processor, the at least two operating systems communicate via the first bus, and the at least two operating systems realize control to the hardware controller via the second bus. An embedded system characterized by the above.

2. The at least two operating systems include a first operating system and a second operating system, the first operating system controls, based on the processor, a target hardware controller to execute a target operating service, and when the target operating service is executed to a target service state, the first operating system releases the target hardware controller via the second bus, wherein the second operating system controls, via the second bus, the target hardware controller to execute the target operating service. The embedded system according to Claim 1, characterized by the above.

3. 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 inherit 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 when the service attribute of the target operating service reaches a target service attribute, the first operating system releases the target hardware controller via the second bus. The embedded system according to Claim 2, characterized by the above.

4. The first operating system determines whether the second operating system inherits the target hardware controller in response to the first interrupt request, The embedded system according to claim 3, wherein the first operating system releases the target hardware controller via the second bus when the second operating system inherits the target hardware controller.

5. The first operating system transmits a second interrupt request to the second operating system via the first bus when the second operating system does not inherit the target hardware controller, and the second interrupt request is used to indicate that the second operating system rejects inheriting the target hardware controller. The embedded system according to claim 4, characterized in that it is used.

6. The first operating system transmits a third interrupt request to the second operating system, and the third interrupt request is used to indicate that the first operating system has already released the target hardware controller, 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.

7. The at least two operating systems include a first operating system and a second operating system, The first operating system is executed based on a target processor core in the processor, When the first operating system executes up to the target system state, it releases the target processor core, The second operating system adds the target processor core to a scheduling resource pool of the second operating system, and the scheduling resource pool includes a processor core in the processor assigned to the second operating system. The embedded system according to any one of claims 1 to 6, characterized in that it is included.

8. The second operating system transmits a fourth interrupt request to the first operating system via the first bus, and the fourth interrupt request is used to request to occupy the target processor core. 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 the system attribute reaches the target system attribute. The embedded system according to claim 7, characterized in that.

9. The first operating system determines whether the second operating system occupies the target processor core in response to the fourth interrupt request. The first operating system releases the target processor core when the second operating system occupies the target processor core. The embedded system according to claim 8, characterized in that.

10. When the second operating system does not occupy the target processor core, the first operating system transmits a fifth interrupt request to the second operating system via the first bus, and the fifth interrupt request is used to indicate that the second operating system is refused to occupy the target processor core. The embedded system according to claim 9, characterized in that.

11. The first operating system transmits a sixth interrupt request to the second operating system, and the sixth interrupt request is used to indicate that the first operating system has already released the target processor core. The second operating system adds the target processor core into the scheduling resource pool in response to the sixth interrupt request. The embedded system according to claim 7, characterized in that.

12. The at least two operating systems include a first operating system and a second operating system. The target processor core in the processor has already been added to the scheduling resource pool of the second operating system, and the scheduling resource pool includes the processor cores assigned to the second operating system. When the first operating system is woken up, the second operating system releases the target processor core. The embedded system according to claim 1, wherein the first operating system is executed based on the target processor core.

13. When the second operating system detects that the first operating system is woken up, the second operating system releases the target processor core, or When the first operating system is woken up, the second operating system sends a seventh interrupt request to the second operating system. The seventh interrupt request is used to request the second operating system to release the target processor core. The embedded system according to claim 12, wherein the second operating system releases the target processor core in response to the seventh interrupt request.

14. The at least two operating systems include a first operating system and a second operating system. The chip further includes a storage space. The at least two operating systems control the storage space via the first bus. In the process of the first operating system being executed based on the processor, service data is generated. 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. The embedded system according to claim 1, wherein the second operating system reads the service data from the storage space in response to the eighth interrupt request.

15. The first operating system executed periodically based on the processor, or executed based on the processor in response to a received wake-up request, or executed based on the processor according to the degree of compatibility between the current operating service generated by the processor and the first operating system, the embedded system according to claim 1.

16. the first operating system sleeps after execution, the second operating system adds the target processor core used by the first operating system to the scheduling resource pool during the sleep period of the first operating system, the scheduling resource pool includes other processors in the processor excluding the target processor core, the embedded system according to claim 15.

17. the at least two operating systems communicate via a communication protocol arranged by the first bus, or the at least two operating systems communicate via the communication hardware controller in the first bus, the second bus and the hardware controller, the embedded system according to claim 1.

18. 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, the mailbox hardware module sends the system interrupt request to the other one of the at least two operating systems via the second bus and the first bus, the embedded system according to claim 17.

19. The at least two operating systems include a first operating system and a second operating system, the first operating system monitors operating services executed by the second operating system via the first bus, the first operating system is characterized in that when there is an abnormal operating service among the operating services executed by the second operating system, it takes over the abnormal operating service via the first bus. The embedded system according to claim 1.

20. the first operating system receives a heartbeat signal of an operating service executed by the second operating system via the first bus, the first operating system is characterized in that it takes over, as the abnormal operating service, an operating service whose frequency of the heartbeat signal does not match a corresponding target frequency via the first bus. The embedded system according to claim 19.

21. after taking over the abnormal operating service, the first operating system transmits a restart command to the second operating system via the first bus, and the restart command is used to indicate restarting the abnormal operating service. The embedded system according to claim 19.

22. the chip further includes a storage device, and a startup boot module is stored in the storage device, 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 is characterized in that it boots the startup of the other one of the at least two operating systems. The embedded system according to claim 1.

23. the at least two operating systems include a first operating system and a second operating system, The first operating system controls, based on the processor, the target hardware controller to execute a target operating service. When the target operating service is executed up to a target service state, the first operating system releases the target hardware controller via the second bus. The second operating system controls, via the second bus, the target hardware controller to execute the target operating service. The first operating system is executed based on a target processor core in the processor. When the first operating system is executed up to a target system state, the first operating system releases the target processor core. The second operating system adds the target processor core into 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 chip further includes a storage space. The at least two operating systems control the storage space via the first bus. In a process where the first operating system is executed based on the processor, service data is generated. The first operating system stores the service data in the storage space via the first bus, and transmits an eighth interrupt request to the second operating system via the first bus. The eighth interrupt request is used to request that the second operating system reads 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. The embedded system according to claim 1.

24. The at least two operating systems include a first operating system and a second operating system. 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, realizing communication between the first operating system and the second operating system. The communication value is used to indicate the content of the communication between the first operating system and the second operating system. The embedded system according to claim 1, characterized in that.

25. The chip loads a control value onto the second bus, and the second bus transmits a control signal including the control value to a corresponding register of the hardware controller, realizing control of the hardware controller by the operating system. The control value is used to indicate the content of the control of the hardware controller by the operating system. The embedded system according to claim 1, characterized in that.

26. 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 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. An embedded system, characterized in that.

27. The controller is detecting the service state of the target operating service of the first operating system executed based on the processor, wherein the execution state includes the service state, and detecting the 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 being executed based on a target processor core in the processor. The embedded system according to claim 26, characterized in that.

28. When the controller detects that the service state is the target service state, it is used to release the target operating service. The processor resources include the target operating service, and the second operating system is used to execute the target operating service, and / or When the controller detects that the system state is the target system state, it is used to release the target processor core. The processor resources include the target processor core, and the second operating system is used to add the target processor core into the scheduling resource pool of the second operating system. The scheduling resource pool includes the processor cores in the processor assigned to the second operating system. The embedded system according to claim 27 is characterized in that.

29. The embedded system further includes a first service interaction thread executed by the first operating system and a second service interaction thread executed by the second operating system. When the controller obtains a first interrupt request sent by the second service interaction thread to the first service interaction thread, it is used to determine that the service state is detected to be the target service state. The first interrupt request is used to request to inherit the target operating service, or The embedded system according to claim 28 is characterized in that when the service attribute of the target operating service reaches the target service attribute, the controller is used to determine that the service state is detected to be the target service state.

30. The controller Responding to the first interrupt request, determining whether the second operating system inherits the target operating service, and The embedded system according to claim 29, characterized in that when the second operating system inherits the target operating service, it is used to release the target operating service.

31. The embedded system further includes a first service interaction thread executed by the first operating system and a second service interaction thread executed by the second operating system. The embedded system according to claim 30, characterized in that when the second operating system does not inherit the target operating service, the first service interaction thread is used to send a second interrupt request to the second service interaction thread, and the second interrupt request is used to indicate that the second operating system rejects inheriting the target operating service.

32. The embedded system further includes a first service interaction thread executed by the first operating system and a second service interaction thread executed by the second operating system. The first service interaction thread is used to send a third interrupt request to the second service interaction thread, and the third interrupt request is used to indicate that the target hardware controller has already been released. The embedded system according to claim 28, characterized in that 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.

33. The embedded system further includes a first service interaction thread executed by the first operating system and a second service interaction thread executed by the second operating system. The controller is used to determine that the system state is the target system state when it obtains a fourth interrupt request sent by the second service interaction thread to the first service interaction thread, and the fourth interrupt request is used to request to occupy the target processor core, or The controller is used to determine that the system state is the target system state when the system attributes of the first operating system reach the target system attributes, according to the embedded system described in claim 28.

34. The controller determines whether the second operating system occupies the target processor core in response to the fourth interrupt request, and is used to release the target processor core when the second operating system occupies the target processor core, according to the embedded system described in claim 33.

35. The embedded system further includes a first service interaction thread executed by the first operating system and a second service interaction thread executed by 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 is refused to occupy the target processor core, according to the embedded system described in claim 34.

36. The embedded system further includes a first service interaction thread executed by the first operating system and a second service interaction thread executed by the second operating system, wherein the first service interaction thread is used to send a sixth interrupt request to the second service interaction thread, and 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 into the scheduling resource pool in response to the eighth interrupt request, according to the embedded system described in claim 28.

37. The controller further detecting whether the target processor core in the processor is released when the target processor core in the processor has already been added to the scheduling resource pool of the second operating system and the first operating system is woken up and executed, wherein the scheduling resource pool includes the processor cores in the processor assigned to the second operating system, and The embedded system according to claim 26, wherein when the second operating system detects that the target processor core has already been released when the first operating system is woken up, the second operating system is used to execute the first operating system based on the target processor core.

38. The embedded system further includes a first service interaction thread executed by the first operating system and a second service interaction thread executed by the second operating system, When the first service interaction thread detects that the target processor core is not released, the first service interaction thread is used to send a seventh interrupt request to the second service interaction thread, and the seventh interrupt request is used to request the second operating system to release the target processor core. The embedded system according to claim 37, wherein the second operating system is used to release the target processor core in response to the seventh interrupt request.

39. The embedded system further includes a first service interaction thread executed by the first operating system and a second service interaction thread executed by the second operating system, The first service interaction thread acquires service data generated during the execution of the first operating system based on the processor, stores the service data in a storage space in the processor, and is used to send an eighth interrupt request to the second service interaction thread. The eighth interrupt request is used to request that the second operating system reads the service data from the storage space. The embedded system according to any one of claims 26 to 38, wherein the second operating system is used to read the service data from the storage space in response to the eighth interrupt request.

40. The controller further controls so that the first operating system is periodically executed based on the processor, or responds to a received wake-up request and controls so that the first operating system is executed based on the processor, or is used to control so that the first operating system is executed based on the processor according to the degree of compatibility between the operating service generated by the processor and the first operating system. The embedded system according to claim 26.

41. The controller detects service information of the current operating service generated by the processor, and is used to control so that the first operating system executes the current operating service based on the processor when it is detected that the degree of compatibility between the service information and the first operating system is higher than a threshold value of the degree of compatibility. The embedded system according to claim 40.

42. The controller Detecting the target response speed and / or target resource occupancy of the current operating service, wherein the service information includes the target response speed and / or 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, and, When the target response speed is below the speed threshold and / or the target resource occupancy is below the occupancy threshold, it is used to determine that the fitness between the service information and the first operating system is higher than the fitness threshold. The embedded system according to claim 41, characterized in that.

43. The controller further, It is used to control the first operating system to sleep after execution. The embedded system according to claim 40, characterized in that.

44. The embedded system further includes a first service interaction thread executed by the first operating system and a second service interaction thread executed by the second operating system, The first service interaction thread is used to notify the second service interaction thread to allow it to occupy the processor core used by the first operating system, The second operating system is used to add the target processor core used by the first operating system into the scheduling resource pool during the sleep period of the first operating system. The scheduling resource pool includes other processors in the processor excluding the target processor core. The embedded system according to claim 43, characterized in that.

45. The embedded system further includes a service inheritance thread executed by the first operating system, The service inheritance thread monitors the operating services executed in the second operating system, and when it monitors that there is an abnormal operating service among the operating services executed in the second operating system, it is used to inherit the abnormal operating service. The embedded system according to claim 26, characterized in that.

46. The service inheritance thread is Receiving a heartbeat signal of each operating service executed in the second operating system, and The embedded system according to claim 45, characterized in that it is used to determine an operating service whose frequency of the heartbeat signal does not match a corresponding target frequency as the abnormal operating service.

47. The service inheritance thread further After inheriting the abnormal operating service by the first operating system, it is used to send a restart command to the second operating system, and the restart command is used to indicate restarting the abnormal operating service. The embedded system according to claim 45, characterized in that.

48. The embedded system further includes a startup boot module, The startup boot module is used to boot the startup of the first operating system and boot the startup of the second operating system. The embedded system according to claim 26, characterized in that.

49. A method for controlling the execution of an operating system, comprising: Detecting an execution state of a first operating system during an execution process, wherein the first operating system and the second operating system are executed based on a processor; and Controlling processor resources used by the first operating system based on the execution state.

50. The step of detecting the execution state of the first operating system during the execution process is Detecting a service state of a target operating service of the first operating system executed based on the processor, wherein the execution state includes the service state, and Detecting a system state of the first operating system, wherein the execution state includes the system state, and the first operating system is executed based on a target processor core in the processor, the method according to claim 49, characterized by including at least one of the steps of

51. The step of controlling processor resources used by the first operating system based on the execution state When it is detected that the service state is a target service state, releasing the target operating service, wherein the processor resources include the target operating service, and the second operating system is used to execute the target operating service, and When it is detected that the system state is a target system state, releasing the target processor core, wherein the processor resources include the target processor core, and the second operating system is used to add the target processor core into a scheduling resource pool of the second operating system, and the scheduling resource pool includes processor cores in the processor assigned to the second operating system, the method according to claim 50, characterized by including at least one of the steps of

52. When the second operating system obtains a first interrupt request sent by the first operating system, determining that it is detected that the service state is the target service state, wherein the first interrupt request is used to request to inherit the target operating service, or The method according to claim 51, further comprising the step of determining that when the service attribute of the target operating service reaches the target service attribute, the service state is detected to be the target service state.

53. When it is detected that the service state is the target service state, the step of releasing the target operating service comprises: responding to the first interrupt request and determining whether the second operating system inherits the target operating service; The method according to claim 52, further comprising the step of releasing the target hardware controller when the second operating system inherits the target hardware controller.

54. When the second operating system obtains a fourth interrupt request sent to the first operating system, the step of determining that the system state is detected to be the target system state, wherein the fourth interrupt request is used to request to occupy the target processor core, or The method according to claim 51, further comprising the step of determining that when the system attribute of the first operating system reaches the target system attribute, the system state is detected to be the target system state.

55. When it is detected that the system state is the target system state, the step of releasing the target processor core comprises: responding to the fourth interrupt request and determining whether the second operating system occupies the target processor core; The method according to claim 54, further comprising the step of releasing the target processor core when the second operating system occupies the target processor core.

56. obtaining service data generated during the process in which the first operating system is executed based on the processor; storing the service data in a storage space in the processor; A step of transmitting an eighth interrupt request to the second operating system, wherein 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 is used to read the service data from the storage space in response to the eighth interrupt request. The method according to any one of claims 49 to 55, further comprising the step of

57. Controlling the first operating system to be periodically executed based on the processor, or Responding to a received wake-up request and controlling the first operating system to be executed based on the processor, or The method according to claim 49, further comprising controlling the first operating system to be executed based on the processor according to a degree of fitness between an operating service generated by the processor and the first operating system.

58. The step of controlling the first operating system to be executed based on the processor according to a degree of fitness between an operating service generated by the processor and the first operating system is Detecting service information of a current operating service generated by the processor; and When it is detected that the degree of fitness between the service information and the first operating system is higher than a threshold value of the degree of fitness, controlling the first operating system to execute the current operating service based on the processor. The method according to claim 57, characterized by including

59. Monitoring an operating service executed by the second operating system; and When it is monitored that there is an abnormal operating service among the operating services executed by the second operating system, the method according to claim 49, further comprising the step of the first operating system taking over the abnormal operating service.

60. An execution control device for an operating system, comprising A first detection module configured to detect an execution state of the first operating system during an execution process, the first detection module being for the first operating system and the second operating system to be executed based on a processor An operating system execution control device, characterized by comprising: a control module configured to control processor resources used by the first operating system based on the execution state. **Claim 61** A chip including at least one of a programmable logic circuit and executable instructions, the chip being executed by an electronic device and used to implement the method according to any one of claims 49 to 59. **Claim 62** A BMC chip including a memory unit and a processing unit connected to the memory unit, the memory unit being configured to store a program, and the processing unit being configured to execute the program to execute the method according to any one of claims 49 to 59. **Claim 63** 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 realizes the method according to any one of claims 49 to 59. **Claim 64** 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 complete mutual communication via the bus, the storage device is configured to store a computer program, and the processor realizes the method according to any one of claims 49 to 59 when executing the program stored by the storage device. **Claim 65** A non-volatile readable storage medium storing a computer program, wherein when the computer program is executed by a processor, the computer program realizes the steps of the method according to any one of claims 49 to 59. **Claim 66** An electronic device including a memory device, a processor, and a computer program stored in the memory device and executable by the processor, wherein: When the processor executes the computer program, the electronic device is characterized in that it realizes the steps of the method according to any one of claims 49 to 59.

Images