Operation system running control method and device, and embedded system and chip

Abstract

The embodiment of the present application provides a kind of operating system running control method and device, and embedded system and chip, wherein the embedded system includes: chip and at least two operating systems, wherein the chip includes processor, hardware controller, first bus and second bus, wherein the bandwidth of first bus is higher than the bandwidth of second bus, and first bus is configured as multi-master multi-slave mode, and second bus is configured as one master multi-slave mode;At least two operating systems are based on processor running;At least two operating systems communicate by first bus;At least two operating systems realize the control to hardware controller by second bus.By the present application, the problem that the operating efficiency of operating system is low is solved, and then the effect of improving the operating efficiency of operating system is achieved.

Description

Technical Field

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

[0002] Current servers, personal computers, industrial control computers, and other equipment mostly employ an operating system plus hardware components, such as CPLD (Complex Programmable Logic Device), EC (Embedded Controller) chips, or control chips, to achieve device control. However, using CPLD, EC, and control chips inevitably increases system costs. Moreover, the addition of these hardware logic devices necessitates cross-device interaction between systems, severely impacting the efficiency of the operating system.

[0003] There is still no effective solution to the problem of low operating system efficiency in related technologies. Summary of the Invention

[0004] This application provides an operating system operation control method and apparatus, as well as an embedded system and chip, to at least solve the problem of low operating efficiency of operating systems in related technologies.

[0005] According to one embodiment of this application, an embedded system is provided, comprising: a chip and at least two operating systems, wherein... The chip includes a processor, a hardware controller, a first bus, and a second bus, wherein the bandwidth of the first bus is higher than that of the second bus, and the first bus is configured in a multi-master multi-slave mode, while the second bus is configured in a single-master multi-slave mode; the at least two operating systems run on the processor; the at least two operating systems communicate through the first bus; and the at least two operating systems control the hardware controller through the second bus.

[0006] According to another embodiment of this application, another embedded system is provided, including: a first operating system, a second operating system, a controller, and a processor, wherein the first operating system and the second operating system run on the processor, and the controller is used to detect the running state of the first operating system during operation and control the processor resources used by the first operating system according to the running state.

[0007] According to another embodiment of this application, an operating system operation control method is provided, comprising: The running status of the first operating system during operation is detected, wherein the first operating system and the second operating system run based on the processor; Control the processor resources used by the first operating system based on its running status.

[0008] According to another embodiment of this application, an operating system operation control device is provided, comprising: The first detection module is used to detect the running status of the first operating system during operation, wherein the first operating system and the second operating system run based on the processor; The control module is used to control the processor resources used by the first operating system according to the operating status.

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

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

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

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

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

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

[0015] This application provides a first operating system and a second operating system that run on a processor. The first operating system's running status is monitored, and the processor resources used by the first operating system are controlled based on this status. Since both the first and second operating systems run on the same processor, the addition and deployment of hardware components are avoided, reducing system costs. Furthermore, the processor resources used by the operating systems can be controlled during operation, thus rationally utilizing processor resources to support inter-system operation. Therefore, this solves the technical problem of low operating system efficiency and achieves the technical effect of improving operating system efficiency. Attached Figure Description

[0016] Figure 1 This is a schematic diagram of the hardware environment for an operating system operation control method according to an embodiment of this application; Figure 2 This is a flowchart of an operating system operation control method according to an embodiment of this application; Figure 3 This is a schematic diagram of an operational business takeover process according to an embodiment of this application; Figure 4 This is a schematic diagram of a processor core occupancy process according to an embodiment of this application; Figure 5 This is a schematic diagram of a processor resource control process according to an embodiment of this application. Figure 1 ; Figure 6 This is a schematic diagram of a processor resource control process according to an embodiment of this application. Figure 2 ; Figure 7 This is a schematic diagram of a business data interaction process according to an embodiment of this application; Figure 8 This is a schematic diagram of the operation process of a first operating system according to an embodiment of this application. Figure 1 ; Figure 9 This is a schematic diagram of the operation process of a first operating system according to an embodiment of this application. Figure 2 ; Figure 10 This is a schematic diagram of a system anomaly monitoring process according to an embodiment of this application; Figure 11 This is a schematic diagram of an embedded system according to an embodiment of this application. Figure 1 ; Figure 12 This is a structural block diagram of an optional BMC chip according to an embodiment of this application; Figure 13This is a schematic diagram of an inter-operating system business data communication process according to an optional implementation of this application; Figure 14 This is a schematic diagram of a business management process in an embedded system according to an optional implementation of this application; Figure 15 This is a schematic diagram of a task scheduling process according to an optional implementation of this application; Figure 16 This is an illustration of an optional embedded system according to an embodiment of this application. Figure 2 ; Figure 17 This is a structural block diagram of an operating system operation control device according to an embodiment of this application. Detailed Implementation

[0017] The embodiments of this application will be described in detail below with reference to the accompanying drawings and examples.

[0018] It should be noted that the terms "first," "second," etc., in the specification, claims, and drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

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

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

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

[0022] This embodiment provides an operating system operation control method, applied to the aforementioned hardware environment. Figure 2 This is a flowchart of an operating system operation control method according to an embodiment of this application, such as... Figure 2 As shown, the process includes the following steps: Step S202: Detect the running status of the first operating system during operation, wherein the first operating system and the second operating system run based on the processor; Step S204: Control the processor resources used by the first operating system according to the running status.

[0023] Through the above steps, the first and second operating systems run on the processor. The system detects the running status of the first operating system and controls the processor resources used by it based on this status. Since both the first and second operating systems run on the same processor, the addition and deployment of hardware components are avoided, reducing system costs. Furthermore, the processor resources used by the operating systems can be controlled during operation, thus rationally utilizing processor resources to support inter-system operation. Therefore, the technical problem of low operating system efficiency can be solved, achieving the technical effect of improving operating system efficiency.

[0024] The entities performing the above steps can be servers, devices, motherboards, chips, processors, embedded systems, etc., but are not limited to these.

[0025] Optionally, in this embodiment, the first operating system and the second operating system may be, but are not limited to, two heterogeneous or homogeneous operating systems, that is, the first operating system and the second operating system may be of the same or different types.

[0026] Taking the first and second operating systems as heterogeneous operating systems as an example, the first and second operating systems can be operating systems with different sensitivities to response time. For example, the first operating system is more sensitive to response time than the second operating system. Alternatively, the first and second operating systems can be operating systems with different resource consumption. For example, the first operating system consumes less resources for business operations than the second operating system.

[0027] The aforementioned first and second operating systems may be, but are not limited to, two heterogeneous operating systems deployed on the processor of an embedded system, i.e., embedded operating systems. Embedded operating systems can be divided into real-time operating systems (RTOS) and non-real-time operating systems according to their sensitivity to response time. Real-time operating systems may include, but are not limited to, Free RTOS (Free Real-Time Operating System) and RT Linux (RealTime Linux). Non-real-time operating systems may include, but are not limited to, contiki (Contiki Operating System), HeliiOS (Helix Operating System), and Linux (Linux Operating System), etc.

[0028] An embedded system is a device used to control, monitor, or assist in the operation of machines and equipment; it is a dedicated computer system. Embedded systems are application-centric, based on computer technology, and feature customizable hardware and software to meet the stringent requirements of application systems regarding functionality, reliability, cost, size, and power consumption. Defined from the perspective of application objects, an embedded system is a combination of software and hardware, and may also encompass mechanical and other auxiliary devices.

[0029] From a hardware perspective, an embedded system can include, but is not limited to, hardware devices such as processors, memory, and peripheral circuits. The aforementioned first and second operating systems run on the processor of the embedded system. From a software perspective, it can include, but is not limited to, low-level drivers, operating systems, and applications. The aforementioned first and second operating systems constitute the operating systems of the embedded system.

[0030] Optionally, in this embodiment, the above-mentioned operating system operation control method may be executed by, but is not limited to, control logic implemented in the embedded system. This control logic realizes the control, allocation and scheduling of hardware and software resources such as heterogeneous dual operating systems, processors and memory in the embedded system.

[0031] The aforementioned operating system operation control method may be executed by, but is not limited to, the first operating system, or by a resource control function module set on the first operating system.

[0032] In the technical solution provided in step S202 above, during the operation of the first operating system, its operating status can, but is not limited to, represent its operating condition. This operating condition can, but is not limited to, be single-dimensional, or it can, but is not limited to, be a comprehensive consideration of multiple dimensions. For example, the operating status can, but is not limited to, include the usage of hardware and software resources, the execution of instructions, the operation of business functions, etc.

[0033] Optionally, in this embodiment, the operation process of the first operating system may refer to, but is not limited to, the entire process from power-on to power-off. During this process, the first operating system may be, but is not limited to, always awake, or may have both a wake-up phase and a sleep phase.

[0034] 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, on-processor storage space (such as memory, cache), timers, registers, input / output interfaces, etc.

[0035] Optionally, in this embodiment, the control of processor resources can be individual control of one type of processor resource, or, but is not limited to, coordinated control of multiple processor resources.

[0036] Optionally, in this embodiment, the control of processor resources may include, but is not limited to, operations such as releasing, occupying, allocating, and reclaiming. By rationally controlling the processor resources used by the first operating system based on its running state, resource utilization and the operating efficiency of the operating system can be improved.

[0037] In one exemplary embodiment, the detected operating state can determine the processor resources to be controlled. For example, detecting the service state can control the adjustment of operational services, while detecting the system state can control the use of processor cores. Different detection objects can also be set according to the processor resources to be controlled. For example, if adjustments to operational services are needed, the service state can be detected; if the use of processor cores needs to be controlled, the system state can be detected.

[0038] On the one hand, the service status of the first operating system running the operational services can reflect the operating status of the first operating system. Alternatively, if it is necessary to control the operational services on the operating system, the service status of the operational services can be detected. For example, in step S202 above, the service status of the target operational service run by the first operating system based on the processor can be detected, but is not limited to, the operational status including the service status.

[0039] Optionally, in this embodiment, the target operation service may be, but is not limited to, operation services that have certain requirements on the system's operating performance or operating environment, such as: fan control services that have certain requirements on running time, log backtracking services that have certain requirements on data storage space, interface switching services that have certain requirements on response speed, and hardware interface waveform signal simulation services, etc.

[0040] Optionally, in this embodiment, the business status of the operation service can represent, but is not limited to, the operation status of the operation service in various dimensions, such as: whether it is interrupted, whether it has run to a certain extent (e.g., whether the running time has reached a threshold, whether the running result has reached a certain preset result), etc.

[0041] If the business state reaches the target business state, that is, the operation business has run to a certain extent, then control operations matching the target business state can be executed on the business. This enables the transfer of the operation business from one operating system to another, the starting and stopping of the operation business, the suspension and resumption of the operation business, and other controls adapted to the current business state. For example, in step S204 above, when the business state is detected to be the target business state, the target operation business is released. Here, the processor resources include the target operation business, and the second operating system is used to run the target operation business.

[0042] Optionally, in this embodiment, if the target operation service reaches a certain state, such as being interrupted or reaching a certain stage (e.g., runtime reaching a threshold, running result reaching a preset result), the target operation service on the first operating system is released, and the target operation service continues to run on the second operating system. This enables the operation service to run alternately between operating systems, allowing the operation service to run on an operating system more suitable for its operation.

[0043] When the business state of the target operation service running on the first operating system reaches the target business state, it can be due to two reasons. First, the operation of the target operation service on the first operating system may be interrupted by the second operating system. For example, if a first interrupt request is received from the second operating system to the first operating system, the business state is determined to be the target business state. The first interrupt request is used to request takeover of the target operation service. Second, the business attributes of the target operation service may reach the target business attribute. For example, if the business attributes of the target operation service reach the target business attribute, the business state is determined to be the target business state.

[0044] Optionally, in this embodiment, the timing of the operating system switch for the target operation service can be determined by, but is not limited to, the second operating system. When the second operating system decides to take over the target operation service, it can send a first interrupt request to the first operating system to instruct it to take over the target operation service. When the first interrupt request is received, it can be considered that the first operating system has reached the target service state for the operation of the target operation service. In response to the first interrupt request, the target operation service can be released and the second operating system can take over the operation of the target operation service.

[0045] Optionally, in this embodiment, the service attributes of the target operation service may include, but are not limited to, runtime, execution result, execution load, etc. The runtime reaching the target service attribute may be, but is not limited to, a preset runtime duration; the execution result reaching the target service attribute may be, but is not limited to, the target operation service producing a preset execution result; and the execution load reaching the target service attribute may be, but is not limited to, the execution resources occupied by the target operation service exceeding or about to exceed the capacity of the first operating system.

[0046] Optionally, in this embodiment, when the target operation service should switch operating systems can be determined by, but is not limited to, the service attributes of the target operation service itself. If the target operation service runs to the point where its service attributes reach the target service attributes, it can be considered that the first operating system has reached the target service state for the operation of the target operation service, and the second operating system can take over the operation of the target operation service.

[0047] In one exemplary embodiment, a determination mechanism may be established, but is not limited to, to determine the eligibility of the second operating system to take over the target operating services. For example, upon receiving a first interrupt request, the mechanism responds to the first interrupt request and determines whether the second operating system should take over the target operating services; if the second operating system takes over the target hardware controller, the target operating services are released.

[0048] Optionally, in this embodiment, when the first interrupt request is received, the target operation service running by the first operating system may not be released immediately. Instead, it may be determined whether the second operating system will take over the target operation service, thereby determining the qualification of the second operating system to take over the target operation service. If it is determined that the second operating system will take over the target operation service, the target operation service running by the first operating system will be released.

[0049] In the mechanism for determining the eligibility of a second operating system to take over the target operating service, if the second operating system is not qualified to take over the target operating service, its takeover can be refused. For example, after determining whether the second operating system should take over the target operating service, if it is not qualified, a second interrupt request is sent to the second operating system, whereby the second interrupt request is used to indicate that the second operating system's takeover of the target operating service is refused.

[0050] Optionally, in this embodiment, the refusal of the second operating system's takeover of the target operation service can be indicated or notified to the second operating system by sending an interrupt request between the systems, but is not limited to this method.

[0051] Optionally, in this embodiment, if the target operation service is not taken over by the second operating system, the second interrupt request may not be sent. The first operating system does not release the target operation service and continues to run the target operation service, and the second operating system will not be able to take over the target operation service.

[0052] After sending a second interrupt request to the second operating system to refuse the second operating system's takeover of the target operation service, the first operating system can continue to run the target operation service until the conditions for the second operating system to take over the target operation service are met (such as the service attributes reaching the target attributes). After that, the first operating system releases the target operation service to the second operating system and notifies the second operating system to take over its operation.

[0053] After the target operation service running on the first operating system is released, the second operating system can proactively detect that the target operation service has been released and take over the target operation service. Alternatively, if the second operating system proactively sends a first interrupt request to request takeover of the target operation service, the second operating system can default to directly taking over the target operation service as long as it does not receive a second interrupt request to refuse its takeover of the target operation service within a certain period of time, thereby improving the takeover efficiency of the target operation service.

[0054] If the target operation service running on the first operating system is released, an interrupt request can be proactively sent to the second operating system to notify it that the target operation service has been released. For example, a third interrupt request can be sent to the second operating system, where the third interrupt request indicates that the target operation service has been released, and the second operating system responds to the third interrupt request to run the target operation service.

[0055] If the first operating system actively releases the target operation service when the service attributes of the target operation service are met, it can send a third interrupt request to the second operating system to notify the second operating system that the target operation service has been released. Upon receiving the third interrupt request, the second operating system will take over the subsequent operation of the target operation service.

[0056] Figure 3 This is a schematic diagram of an operational service takeover process according to an embodiment of this application, such as... Figure 3 As shown, the second operating system sends a first interrupt request to the first operating system to request takeover of the target operating service running on the first operating system. If the first operating system allows the second operating system to take over the target operating service, the target operating service is released and taken over by the second operating system, which then runs on the second operating system. If the first operating system does not allow the second operating system to take over the target operating service, a second interrupt request is sent to the second operating system to refuse its takeover, and the target operating service continues to run on the first operating system.

[0057] On the other hand, the system state of the first operating system can reflect its operating status. Based on this system state, reasonable control can be exercised over, but is not limited to, the processor core used by the first operating system. Alternatively, if control over the processor core used by the operating system is required, the system state of the operating system can be detected. For example, in step S202 above, the system state of the first operating system can be detected, but is not limited to, where the operating status includes the system state, and the first operating system runs based on the target processor core in the processor.

[0058] Optionally, in this embodiment, the target processor core may be, but is not limited to, the processor core allocated in the processor for running the first operating system, and the number of target processor cores may be, but is not limited to, one or more.

[0059] Optionally, in this embodiment, the system state of the operating system may, but is not limited to, represent the operating status of the operating system in various dimensions, such as: whether it is interrupted, whether it has run to a certain extent (e.g., whether the running time has reached a threshold, whether the running result has reached a certain preset result), etc.

[0060] If the system state reaches the target system state, that is, the operating system has reached a certain stage of operation, then control operations matching the target system state can be executed on the processor cores used by the operating system, thereby achieving reasonable allocation and utilization of the processor cores. For example, in step S204 above, when the system state is detected to be the target system state, the target processor core is released. Here, processor resources include the target processor core, and the second operating system is used to add the target processor core to the scheduling resource pool of the second operating system. The scheduling resource pool includes the processor cores allocated to the second operating system in the processor pool.

[0061] Optionally, in this embodiment, if the system state of the first operating system reaches the target system state, such as being interrupted, or reaching a certain stage (e.g., runtime reaches a threshold, runtime result reaches a preset result, runtime load is lower than a preset value), then the target processor core used by the first operating system is released, and the target processor core is used by the second operating system. This enables the alternating use of the processor core between operating systems, allowing for more rational utilization of the processor core.

[0062] For the first operating system to reach the target system state, one possibility is that the first operating system is interrupted by the second operating system. For example, if a fourth interrupt request is received from the second operating system to the first operating system, the system state is determined to be the target system state. The fourth interrupt request is used to request the use of the target processor core. Alternatively, the system attributes of the first operating system may reach the target system attributes. For example, if the system attributes of the first operating system reach the target system attributes, the system state is determined to be the target system state.

[0063] Optionally, in this embodiment, the timing of the operating system switch for the target processor core can be determined by the second operating system, but is not limited to. When the second operating system decides to take over the target processor core, it can send a fourth interrupt request to the first operating system to instruct it to take over the target processor core. When the fourth interrupt request is received, it can be considered that the system state of the first operating system has reached the target system state. In response to the fourth interrupt request, the target processor core can be released, and the second operating system can take over the target processor core and add it to the scheduling resource pool for use.

[0064] Optionally, in this embodiment, after receiving the fourth interrupt request sent by the second operating system to the first operating system, the data currently running in the first operating system can be pushed onto the stack, the first operating system enters a hibernation state, and the second operating system occupies the target processor kernel for scheduling and use.

[0065] Optionally, in this embodiment, the second operating system may, but is not limited to, initiate a fourth interrupt request based on its own needs for processor core resources. For example, the second operating system may detect whether the resource utilization rate of the core allocated to it is higher than a certain threshold, or detect whether the remaining resources of the core allocated to it are sufficient to run the next process. If the resource utilization rate is higher than a certain threshold or the remaining resources are insufficient to run the next process, it can be considered that the second operating system needs additional processor cores. The second operating system may actively send a fourth interrupt request to the first operating system to request to occupy the target processor core, thereby reducing its operating pressure or supporting the running of the next process.

[0066] In an alternative implementation, when the second operating system (e.g., Linux) detects that the resource utilization of the core allocated to it is high (e.g., the utilization rate is higher than 95% of the total resources), it can send a fourth interrupt request to the first operating system (e.g., RTOS). After receiving the fourth interrupt request, the first operating system (RTOS) saves the current business context of the core it is running (e.g., pushes the running data onto the stack) and releases the target processor core it is using. The second operating system (Linux) then occupies the target processor core and allocates the threads that need to run to the target processor core, or schedules the threads on other processor cores with high utilization rates to run on the target processor core.

[0067] Optionally, in this embodiment, the system attributes of the operating system may include, but are not limited to, system runtime, running results, running load, etc. The system runtime reaching the target system attribute may include, but is not limited to, reaching a preset runtime; the system running results reaching the target system attribute may include, but are not limited to, the operating system producing a preset running result; and the system running load reaching the target system attribute may include, but is not limited to, the operating system's resource utilization rate being lower than or about to be lower than its set minimum utilization rate.

[0068] Optionally, in this embodiment, when the target processor core switches to the operating system can be determined by, but is not limited to, the system attributes of the operating system itself. If the operating system runs to the point where its system attributes reach the level of the target system attributes, it can be considered that the operating system's system state has reached the target system state, and the second operating system can occupy the target processor core.

[0069] In one exemplary embodiment, a determination mechanism may be established, but is not limited to, to determine whether the second operating system is qualified to occupy the target processor core. For example, upon receiving a fourth interrupt request, the mechanism responds to the fourth interrupt request and determines whether the target processor core is occupied by the second operating system; if the target processor core is occupied by the second operating system, the mechanism releases the target processor core.

[0070] Optionally, in this embodiment, when a fourth interrupt request is received, the target processor core may not be released immediately. Instead, it may be determined whether the target processor core is occupied by the second operating system, thereby determining the eligibility of the second operating system to occupy the target processor core. If it is determined that the target processor core is occupied by the second operating system, the target processor core is released and occupied by the second operating system.

[0071] In the mechanism for determining the eligibility of a second operating system to occupy a target processor core, if the second operating system is not eligible to occupy the target processor core, its occupation of the target processor core can be refused. For example, if the second operating system is not eligible to occupy the target processor core, a fifth interrupt request can be sent to the second operating system, where the fifth interrupt request is used to indicate that the second operating system's occupation of the target processor core should be refused.

[0072] Optionally, in this embodiment, the refusal of the second operating system's access to the target processor core can be indicated or notified to the second operating system by sending an interrupt request between the systems, but is not limited to this method.

[0073] Optionally, in this embodiment, if the target processor core is not occupied by the second operating system, the second interrupt request may not be sent. The first operating system does not release the target processor core and continues to occupy it, while the second operating system is unable to occupy the target processor core.

[0074] After sending a fifth interrupt request to the second operating system to refuse the second operating system's use of the target processor core, the first operating system can continue to use the target processor core to process operational tasks until the conditions for the second operating system to use the target processor core are met (e.g., system attributes meet the target system attributes). After that, the first operating system releases the target operational tasks to the second operating system and notifies the second operating system to take over the operation.

[0075] Figure 4 This is a schematic diagram of a processor core occupancy process according to an embodiment of this application, such as... Figure 4 As shown, the first operating system runs on the target processor core. During operation, the second operating system sends a second interrupt request to the first operating system, requesting to occupy the target processor core it is using. If the second operating system is allowed to occupy the target processor core, it releases the target processor core and the second operating system occupies it, adding it to the resource scheduling pool. If the second operating system is not allowed to occupy the target processor core, a fifth interrupt request is sent to the second operating system to refuse.

[0076] After the target processor core used by the first operating system is released, the second operating system can proactively detect that the target processor core has been released and occupy it. Alternatively, if the second operating system actively sends a fourth interrupt request to request the occupation of the target processor core, the second operating system can default to directly occupying the target processor core as long as it does not receive a fifth interrupt request to refuse its occupation of the target processor core within a certain period of time, thereby improving the utilization efficiency of the target processor core.

[0077] If the first operating system actively releases the target processor core it is using, it can proactively send an interrupt request to the second operating system to notify it that the target processor core has been released. For example, it can send a sixth interrupt request to the second operating system, where the sixth interrupt request indicates that the first operating system has released the target processor core, and the second operating system responds to the sixth interrupt request by adding the target processor core to the scheduling resource pool.

[0078] When the system attributes meet the target system attributes, the first operating system actively releases the target processor core and can send a sixth interrupt request to the second operating system to notify the second operating system that the target processor core has been released. Upon receiving the sixth interrupt request, the second operating system occupies the target processor core for resource scheduling and use.

[0079] In an alternative implementation, when the first operating system (such as an RTOS) determines that no threads need to be scheduled during operation (e.g., the operating system's resource utilization is below or about to fall below its set minimum utilization limit), it can trigger the first operating system (RTOS) to actively hibernate. The first operating system (RTOS) sends a sixth interrupt request to the second operating system (such as Linux), saves its running state (e.g., pushes the running data onto the stack), and then hibernates. After receiving the sixth interrupt request, the second operating system (Linux) adds the target processor kernel to its resource scheduling pool for scheduling and use.

[0080] In one optional application scenario, the chip incorporates a dual operating system running on a multi-core CPU. The first operating system can be, but is not limited to, an RTOS, and the second operating system can be, but is not limited to, Linux. CPU core 0 is allocated to the RTOS, and the remaining cores are allocated to Linux. Figure 5 This is a schematic diagram of a processor resource control process according to an embodiment of this application. Figure 1 ,like Figure 5As shown, the RTOS is periodically woken up to run, and the RTOS and Linux alternately occupy and schedule CPU core 0. During the time slice (T4, T5) when the RTOS schedules CPU core 0, Linux generates an interrupt to take over CPU core 0 at time T4-1 (equivalent to the fourth interrupt request mentioned above), causing the RTOS to have to sleep. At this time, the RTOS saves its state in the stack, goes to sleep, and then releases CPU core 0 to Linux for takeover. After Linux completes its scheduling, an interrupt will be generated at time T5-1 to wake up the RTOS, which will then enter the round-robin mode to occupy and schedule CPU core 0 again from time T5-1.

[0081] In this embodiment, the takeover of inter-system operation services and the occupation of processor cores can be, but are not limited to, separate actions. For example, only the operation services can be taken over, or only the processor cores can be occupied. Alternatively, they can be occupied together, that is, both the operation services can be taken over and the processor cores can be occupied.

[0082] In an optional implementation, taking device control services as an example, the second operating system takes over the processor resources of the first operating system. In this implementation, a startup control process for an operating system is provided, which includes the following steps: Step A involves controlling the hardware controller of the target device via a first operating system running on the first processor core through a first bus, thereby controlling the operating status of the target device.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0118] In this embodiment, when the operating system starts, the Second Program Loader (SPL) can be loaded into internal memory, such as the Static Random-Access Memory (SRAM) inside the SOC. The SPL can be responsible for loading the Universal Boot Loader (U-Boot) into the Random-Access Memory (RAM). The Second Program Loader can boot the second operating system and also boot the first operating system.

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

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

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

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

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

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

[0125] To take over fan management as quickly as possible, the RTOS system should be booted first. After the Linux system has booted up, the Linux system should take over fan control. The boot process of a multi-core dual-system may include the following steps: Step 1: Wake up CPU0 when the system is powered on; Step 2: CPU0 runs the specified program in the Boot ROM to load the RTOS system and start it. Step 3: During the RTOS system startup process, wake up CPU1 to boot U-Boot and start the fan control program (FanCtrl_RTOS_APP) in the first operating system. Step 4, CPU1 booting U-Boot can include the SPL stage and the U-Boot stage, and enters the SPL stage by calling SPL; Step 5: In the SPL phase, SPL guides U-Boot to start. Step 6: During the U-Boot phase, load the Linux kernel (CPU1~CPUN) and start the BMC business program and the fan control program (FanCtrl_Linux_APP) in the second operating system.

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

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

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

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

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

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

[0132] In one exemplary embodiment, the first operating system may have a higher priority in occupying the processor cores allocated to it, or the operating system currently using the processor cores allocated to the first operating system may be determined through negotiation among the operating systems, but is not limited to. If the target processor core allocated to the first operating system is already occupied by the second operating system, when the first operating system is woken up and running, it can detect whether the target processor core has been released. If it has been released, the first operating system runs based on the target processor core. If it has not been released, a seventh interrupt request can be sent to the second operating system to request the second operating system to release the target processor core. After the second operating system responds to the seventh interrupt request and releases the target processor core, the first operating system runs based on the target processor core. For example, if the target processor core in the processor has been added to the scheduling resource pool of the second operating system, and the first operating system is woken up and running, it is detected whether the target processor core has been released, wherein the scheduling resource pool includes the processor cores allocated to the second operating system in the processor; if it is detected that the second operating system has released the target processor core when the first operating system is woken up, the first operating system runs based on the target processor core.

[0133] Optionally, in this embodiment, the fact that the target processor core has been added to the scheduling resource pool of the second operating system may, but is not limited to, indicate that the target processor core has been occupied by the second operating system. If the first operating system is woken up and running under these circumstances, the second operating system may actively release the target processor core. Alternatively, it may continue to occupy the target processor core until the first operating system actively requests it to release the target processor core.

[0134] Optionally, in this embodiment, the first operating system detects whether the target processor core has been released. If it detects that the target processor core has not been released, it can request the second operating system to release the target processor core via an interrupt request. For example, if it detects that the target processor core has not been released, it sends a seventh interrupt request to the second operating system, wherein the seventh interrupt request is used to request the second operating system to release the target processor core, and the second operating system is used to respond to the seventh interrupt request to release the target processor core.

[0135] Optionally, in this embodiment, the second operating system may, but is not limited to, directly release the target processor core upon receiving the seventh interrupt request, or may, but is not limited to, determine whether to release the target processor core and then decide whether to immediately release the target processor core to the first operating system, or to continue running to obtain the running result before releasing the target processor core to the first operating system.

[0136] In the above-mentioned optional application scenarios, Figure 6 This is a schematic diagram of a processor resource control process according to an embodiment of this application. Figure 2 ,like Figure 6 As shown, during the time slice (T3, T4) of Linux scheduling CPU core 0, the RTOS is in a sleep state. At time T3-1, the RTOS may be woken up due to an interrupt event reported by the hardware. Linux will preserve the context of the process running on CPU core 0. The RTOS occupies CPU core 0. After processing the interrupt event reported by the hardware, it enters a sleep state again at time T4-1. At this time, the RTOS reports the interrupt to release CPU core 0 to Linux. Linux continues to schedule CPU core 0 according to the set period and restores the running process.

[0137] During the operation of an operating system, business data can be exchanged. This exchange can be achieved, but is not limited to, using a combination of storage space and interrupt requests for data transmission. Operating systems transfer data through storage space and communicate instructions to each other through interrupt requests. For example: acquiring business data generated by the first operating system during processor operation; storing the business data in the processor's storage space; sending an eighth interrupt request to the second operating system, whereby the eighth interrupt request requests the second operating system to read business data from storage space, and the second operating system responds by reading business data from storage space.

[0138] Optionally, in this embodiment, the first operating system, based on the business data generated during the processor's operation being stored in the processor's storage space, notifies the second operating system through an eighth interrupt request, and the second operating system reads the business data from the storage space, thereby realizing the interaction of business data.

[0139] Optionally, in this embodiment, the business data exchanged between operating systems can be, but is not limited to, any data that needs to be transmitted between systems during the operation of business processes by the operating systems. For example, business process data, business result data, etc.

[0140] Optionally, in this embodiment, the processor's storage space may, but is not limited to, be configured with dedicated storage locations for the interaction process between operating systems, which may be called shared memory. This shared memory may, but is not limited to, be further allocated according to the operating system, that is, each operating system corresponds to a dedicated segment of shared memory.

[0141] Information about the shared memory corresponding to the first operating system (e.g., storage address) can be carried in the eighth interrupt request, which requests the second operating system to read business data from the storage space. The second operating system responds to the eighth interrupt request to read business data from the shared memory it indicates.

[0142] In this embodiment, interrupt requests can be transmitted between systems via, but are not limited to, software protocols, or via hardware modules. Taking the transmission of interrupt requests via a hardware module mailbox as an example, a mailbox channel can be established between the first and second operating systems. Business data is read and written through storage space, while interrupt requests are transmitted through the mailbox channel.

[0143] In one optional implementation, a method for inter-core communication is provided. This method includes the following steps: Step a: The first operating system sends the target data (which may be the aforementioned business data) to the target virtual channel (which may be the aforementioned storage space) in the processor memory.

[0144] Optionally, the first operating system and the second operating system can be real-time operating systems or non-real-time operating systems. The first operating system and the second operating system can be single-core operating systems or multi-core operating systems. The target data is the data to be sent. The target virtual channel is a free storage space in memory. The first operating system sending the target data to the target virtual channel in the processor memory means that the CPU core of the first operating system writes the data to be sent into the target virtual channel.

[0145] Step b: Send an interrupt notification message to the second operating system (which can be the eighth interrupt request mentioned above).

[0146] Optionally, the CPU core of the first operating system sends an interrupt notification message to the CPU core of the second operating system. The interrupt notification message may carry the address of the target virtual channel, which is used to notify the second operating system to obtain the target data from the target virtual channel. The interrupt notification message may be triggered by software or by hardware.

[0147] In step c, the second operating system responds to the interrupt notification message and retrieves the target data from the target virtual channel in memory.

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

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

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

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

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

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

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

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

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

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

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

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

[0160] In an exemplary embodiment, where the first operating system includes an application layer, the application layer provides a human-computer interaction interface. Before the driver layer of the first operating system determines the virtual channel in an idle state in memory, the method further includes: the application layer of the first operating system receiving user-inputted data to be sent through the human-computer interaction interface, encapsulating the data to be sent in a preset format to obtain target data, and calling a data writing function to transmit the target data to the driver layer through a preset communication interface, wherein the preset communication interface is set on the driver layer.

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

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

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

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

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

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

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

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

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

[0170] It should be noted that the data storage area can be divided into n virtual memory channels, each of which can be of different sizes; that is, the sizes of the n virtual channels are successively 2. 0 m、2 1 m、2 2 m、2 3 m …… 2 n-1 m, where m is the size of a storage unit, and the following structure is set as the metadata management memory channel: 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 Among them, `uint32_t Flag` represents the state of the memory channel; for example, 0xA5A5A5A5 indicates that the channel is not empty, otherwise it is empty; `uint16_t ChannelId` represents the channel ID; `uint8_t SrcId` represents the source CPU ID, which points to the CPU that writes data to the memory channel; `uint8_t NetFn` and `uint8_t Cmd` are function parameters; `uint32_t Len` is the length of the data stored in the memory channel; `uint32_t ChannelSize` represents the size of the memory channel; `uint8_t`... `pData` refers to the starting address of the memory channel; `uint8_t CheckSum` refers to the checksum. When the first operating system needs to send data, it calculates the checksum value using a checksum algorithm and sends the checksum value to the second operating system. Upon receiving the data and checksum value, the second operating system calculates its own checksum value using the same algorithm and compares it with the received checksum value. If they match, the received data is valid; otherwise, the data is invalid. Each virtual memory channel corresponds to a structure record. These structure records are stored sequentially at the beginning of the shared memory in ascending order of channel ID. Upon system power-up, these structure records are initialized: `Flag` is initialized to 0 to indicate the channel is empty; `ChannelId` is initialized sequentially to 0, 1, 2, ..., n-1; `ChannelSize` is initialized to the size of the corresponding virtual memory channel; and `pData` is initialized to point to the starting address of the corresponding virtual memory channel.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0186] Before performing a memory allocation operation, configure the memory management information as follows: typedef struct { uint32_t MemReady; uint32_t MemLock; MallocMemInfo_T; Among them, the member variable MemLock of the structure MallocMemInfo_T indicates whether the shared memory has been initialized, and the variable MemReady is 0xA5A5A5A5, which means that the initialization operation has been completed and memory can be dynamically allocated and released normally; the member variable MemReady of the structure MallocMemInfo_T represents whether it is locked.

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

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

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

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

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

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

[0193] In one exemplary embodiment, an interrupt notification message is sent to a second operating system via a software interrupt.

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

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

[0196] In multi-core heterogeneous operating systems, to maximize compatibility with current resource allocation methods, interrupts 8-15 (a total of 8 interrupts) are used to represent the inter-core interrupt vector table. With the first operating system being an RTOS and the second operating system being Linux, a feasible allocation scheme for the vector table is shown in Table 1: Table 1

[0197] In one exemplary embodiment, an interrupt notification message is sent to a second operating system via a hardware interrupt.

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

[0199] In one alternative implementation, a shared memory approach is provided. This approach includes the following steps: Step 101: Receive a memory request instruction and perform a locking operation on the processor's memory. The memory request instruction is used to request the use of the processor's memory.

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

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

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

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

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

[0205] Optionally, if a locking operation fails, the memory can be locked again after a preset waiting period until the locking is successful. For example, the preset waiting period can be 100 microseconds.

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

[0207] Step 102: If the memory is successfully locked, read the memory occupancy status and determine whether there is a free target memory space in the memory based on the memory occupancy status. The size of the target memory space is greater than or equal to the size of the memory requested by the memory request instruction.

[0208] After successfully acquiring the lock, the operating system requests memory from the processor. Optionally, it scans information used to record the memory occupancy status to determine if there is a target memory space. That is, it determines whether there is a contiguous, unoccupied memory space in the processor that can meet the memory usage requirements. Meeting the memory usage requirements means that the size of the memory space is greater than or equal to the size of the memory requested by the operating system.

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

[0210] Step 103: If the target memory space exists in memory, feed back the address information of the target memory space to the sending end of the memory request instruction, update the memory's occupied status, and release the lock on the memory.

[0211] The sending end refers to the operating system that sends the memory request instruction. It should be noted that since the operating system uses shared memory to send and receive data during inter-core communication, and uses the address returned by the requested memory to access data during the data sending and receiving process, it is necessary to determine the address information of the requested memory space.

[0212] Optionally, after a target memory space exists in the processor's memory space that can be used by the operating system, the address information of the target contiguous space is sent to the operating system, and the operating system stores the data to be transferred into the corresponding memory space according to the address information.

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

[0214] The above steps—receiving a memory request instruction and locking the processor's memory (the memory request instruction is used to request the use of processor memory); if the memory is successfully locked, reading the memory's occupied status and determining whether there is a free target memory space in memory based on the memory's occupied status (the size of the target memory space is greater than or equal to the size of the memory requested by the memory request instruction); if the target memory space exists in memory, feeding back the address information of the target memory space to the sender of the memory request instruction, updating the memory's occupied status, and releasing the lock on the memory—solve the problems of low efficiency, poor flexibility, and excessive reliance on the operating system in shared memory among multiple kernels. This achieves the effect of improving the flexibility and efficiency of shared memory and reducing dependence on the operating system.

[0215] In this shared memory method, the memory includes a metadata storage area and a data storage area. The data storage area is used to store business data. The metadata storage area stores a mapping table, which is used to record the occupancy status of the data storage area. Reading the occupancy status of the memory and determining whether there is a free target memory space in the memory based on the occupancy status includes: reading the records 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 records in the mapping table.

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

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

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

[0219] The data storage area is the dynamically allocated memory block area, and the metadata storage area includes the dynamically allocated memory mapping table area. The mapping table area divides the memory page into the same number of records as the number of memory pages in the data storage area, and records these records as memory page records. All memory page records are combined into a mapping table. There is a one-to-one correspondence between all memory page records in the mapping table and all memory pages in the data storage area. Each memory page record represents the allocation status of the corresponding memory page, that is, whether the memory page is occupied.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0239] Optionally, the memory management information consists of a first field and a second field. The first field indicates whether a lock is being acquired, and the second field indicates whether initialization is complete. Before performing a memory allocation operation, the memory management information is configured as follows: typedef struct { uint32_t MemReady; uint32_t MemLock; MallocMemInfo_T; The `MallocMemInfo_T` structure has a member variable `MemLock` (second field information) indicating whether the shared memory has been initialized, and a member variable `MemReady` (first field information) indicating whether it is locked. A value of 0 for `MallocMemInfo_T` indicates that no system or task is currently requesting memory, meaning it is not locked. A value of 0xA5A5A5A5 indicates that a system or task is currently requesting memory, and other systems or tasks will request memory after this request is completed. A value of 0xA5A5A5A5 indicates that the initialization operation has been completed, and memory can be dynamically allocated and released normally.

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

[0241] Optionally, if the operating system needs to occupy the target memory space, by identifying the address information of multiple memory pages in the target memory space, and according to the correspondence between memory pages and memory page records, the memory page records in the mapping table area of ​​the metadata storage area are updated, so that they change from an unoccupied state to an occupied state.

[0242] In one optional implementation, a communication method between operating systems is provided. This method includes the following steps: Step 201: Receive a memory request instruction from the first operating system and perform a locking operation on the processor's memory, wherein the memory request instruction is used to request the use of the processor's memory; It should be noted that, in order to prevent multiple operating systems from failing to request the processor's memory space at the same time, the first operating system requests a lock on the processor's memory when it sends a memory request instruction. Only after the lock request is successful can the memory be requested.

[0243] Optionally, the success of locking can be determined by checking whether the preset variable stored in memory is a preset value. If the preset variable is not a preset parameter value, it means that no other system or task is requesting memory space, and the locking is successful. Otherwise, if the preset variable is a preset parameter, it means that at the current moment, there are other systems or tasks other than the operating system requesting memory space, and the locking fails.

[0244] Step 202: If the memory is successfully locked, read the memory occupancy status and determine whether there is a free target memory space in the memory based on the memory occupancy status. 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, when the lock acquisition is successful, the system scans the information used to record the memory occupancy status according to the memory request instruction issued by the operating system to determine whether there is a target memory space. That is, it determines whether there is a contiguous memory space in the processor that is not occupied. In an exemplary embodiment, it determines whether the size of the contiguous memory space that is not occupied is greater than or equal to the memory size requested by the operating system, and obtains the determination result.

[0245] Step 203: If the target memory space exists in memory, feed back the address information of the target memory space to the first operating system, update the memory occupancy status, and release the lock on the memory. Optionally, after the judgment result indicates that there is a target memory space available for the operating system in the processor's memory space, the address information of the target contiguous space is sent to the operating system, and the operating system stores the data to be transferred into the corresponding memory space according to the address information.

[0246] Furthermore, the processor's memory space occupancy status 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 locking operation before dynamic memory allocation is released.

[0247] 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 contiguous memory space to the second operating system; Optionally, after successfully requesting memory, the first operating system will send the target memory space requested for the target data storage value to be transmitted, and send the address information of the target memory space to the second operating system that cooperates with the first operating system, so as to notify the second operating system to acquire the data.

[0248] Step 205: Receive the acquisition instruction sent by the second operating system based on the address information, and send the target data stored in the target memory space to the second operating system.

[0249] Optionally, after the second operating system receives the address information of the target memory space, it issues a data acquisition instruction. The embedded system receives the instruction and sends the target data stored in the target memory space to the second operating system.

[0250] Through the above steps: receiving a memory request instruction from the first operating system and performing a locking operation on the processor's memory, wherein the memory request instruction is used to request the use of the processor's memory; if the memory is successfully locked, reading the memory's occupied status and determining whether there is a free target memory space in the memory based on the memory's occupied status, wherein the size of the target memory space is greater than or equal to the size of the memory requested by the memory request instruction; if the target memory space exists in the memory, feeding back the address information of the target memory space to the sender of the memory request instruction, updating the memory's occupied status, and releasing the lock on the memory; responding to the storage operation of the first operating system, storing the target data in the target memory space, and sending the address information of the contiguous memory space to the second operating system; receiving a fetch instruction sent by the second operating system based on the address information, and sending the target data stored in the target memory space to the second operating system, this solves the problems of low efficiency, poor flexibility, and excessive dependence on the operating system in shared memory among multiple kernels, thereby improving the flexibility and efficiency of shared memory and reducing dependence on the operating system.

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

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

[0253] In a non-real-time operating system, the address returned by dynamically allocated memory is also a virtual address vData. In a non-real-time operating system, Offset = vData – vBase. Data is sent from the non-real-time operating system to the real-time operating system. The real-time operating system uses the address pData to access the dynamically allocated shared memory, pData = pBase + Offset.

[0254] In a real-time operating system, the address returned by dynamically allocated memory is the physical address pData. In a real-time operating system, Offset = pData – pBase. Data is sent from the real-time operating system to a non-real-time operating system. The non-real-time operating system uses the address vData to access the dynamically allocated shared memory vData = vBase + Offset.

[0255] In an exemplary embodiment, the memory includes a metadata storage area and a data storage area. The data storage area consists of multiple memory pages, each of which stores business data. The metadata storage area stores a mapping table containing multiple records. Each record records the occupied state of a memory page. Reading the occupied state of memory and determining whether there is free target memory space in memory based on the occupied state includes: determining a preset number of memory pages requested by the memory request instruction; sequentially scanning each record from the initial position of the mapping table; and determining that there is target memory space in memory when a preset number of consecutive target records are scanned, wherein the target records indicate that the memory pages are in a free state.

[0256] Optionally, the metadata storage area stored in the processor is obtained, and the mapping table in the metadata storage area is identified. Starting from the index position in the mapping table, each memory page record is traversed. Each memory page record in the mapping table is queried in turn to determine whether there are consecutive memory page records with a free memory page greater than or equal to a preset number. If there are memory page records that meet the above conditions, the existence of the target memory space in the processor is determined by the correspondence between memory page records and memory pages.

[0257] In an exemplary embodiment, when the initial position is the last position in the mapping table, feeding back the address information of the target memory space to the sender of the memory request instruction includes: determining the last scanned target record among a consecutive preset number of target records, and feeding back the starting address of the memory page indicated by the last scanned target record to the sender.

[0258] Optionally, when scanning the mapping table, the scanning method can be selected to scan from the first position of the mapping table or from the last position of the mapping table. When the scanning method is to scan from the last position of the mapping table, the starting address of the last memory page scanned is recorded, and these memory pages are set to NOT null. The starting address is used as the starting address of the entire contiguous memory page for this memory allocation instruction. In an exemplary embodiment, this address is fed back to the operating system that issued the memory allocation instruction, and the operating system performs data writing operations on the memory based on the address information.

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

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

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

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

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

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

[0265] In this embodiment, Figure 7 This is a schematic diagram of a business data interaction process according to an embodiment of this application, such as... Figure 7 As shown, during operation, the first operating system generates business data and determines whether the business data is needed by the second operating system or needs to be sent to the second operating system. At this time, the first operating system stores the business data in the storage space and sends an eighth interrupt request to the second operating system. The second operating system responds to the eighth interrupt request, reads the business data from the storage space, and performs subsequent processing.

[0266] The first operating system may, but is not limited to, have different operating mechanisms, such as: controlling the first operating system to run periodically based on the processor; or, responding to a received wake-up request and controlling the first operating system to run based on the processor; or, controlling the first operating system to run based on the matching degree between the operation services generated on the processor and the first operating system.

[0267] Optionally, in this embodiment, the operating mechanism of the first operating system may include, but is not limited to, periodic operation and triggered operation. Periodic operation can also be called polling mode, and triggered operation can also be called triggering mode, which may include, but is not limited to, two methods: one is request triggering, where the wake-up operation of the first operating system is triggered by a wake-up request; the other is condition triggering, where the wake-up operation of the first operating system is triggered by the matching degree between the operation service and the first operating system.

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

[0269] Depending on the different operating scenarios and system functions, different operating mechanisms can be used to run the first operating system, thereby more flexibly finding an operating mechanism that is more compatible with the current operating scenario and system functions to run the first operating system and improve the processing efficiency of operational business.

[0270] In one alternative implementation, a wake-up strategy for a first operating system (such as an RTOS) in polling mode is provided. Figure 8 This is a schematic diagram of the operation process of a first operating system according to an embodiment of this application. Figure 1 ,like Figure 8 As shown, the round-robin mode is a time-slice-based polling scheduling mode that periodically wakes up the RTOS to run according to a set time. In this mode, during the operation of multiple systems (taking a dual-system of Linux and RTOS as an example), (T0, T1) = (Tn, T(n+1)), where n is a non-zero positive integer. That is, the two systems alternately occupy CPU core 0 for the same amount of time. During the time slice (T0, T1), the RTOS schedules CPU core 0 to run its processes. During the time slice (T1, T2), the Linux schedules CPU core 0 to run its processes. During this time slice, the RTOS is in a sleep state. Subsequent time slices are divided periodically.

[0271] For the request-triggered method in the trigger mode, the wake-up request can be initiated by, but is not limited to, the device connected to the first operating system, or it can be initiated by, but is not limited to, the second operating system.

[0272] In one optional implementation, taking the device triggering the wake-up and operation of the first operating system as an example, a wake-up strategy for the first operating system (such as an RTOS) in a trigger mode is provided. Figure 9 This is a schematic diagram of the operation process of a first operating system according to an embodiment of this application. Figure 2 ,like Figure 9 As shown, the trigger mode can be started by an interrupt initiated by a device in the RTOS bus domain. The RTOS bus domain connects devices 0 to N. When the RTOS is in a sleep state, if device 0 triggers an interrupt to the RTOS at some point, the RTOS will be woken up. After being woken up, the RTOS first triggers an interrupt to preempt CPU core 0 to Linux. After receiving the interrupt, Linux first releases CPU core 0 and saves the context (pushing the running data onto the stack). Then, the RTOS system schedules CPU core 0 to handle the operation indicated by the interrupt triggered by device 0. If the current mode is polling, the subsequent processing is the same as the polling mode described above, and will not be repeated here.

[0273] If the second operating system triggers the wake-up of the first operating system, and the second operating system is currently occupying a processor core allocated to the first operating system, it can directly release that processor core, allowing the first operating system to wake up and use that processor core to handle the operational tasks allocated by the second operating system.

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

[0275] In step 11, the request command can be a hardware interface signal generation command. For example, if the hardware interface signal is a PECI signal, then the request command is a PECI request command based on the PECI protocol.

[0276] Optionally, the hardware interface signal can also be a hardware interface signal of other protocol types, such as HDMI (High Definition Multimedia Interface) signal, RGMII (Reduced Gigabit Media Independent Interface) signal, SGMII (Serial Gigabit Media Independent Interface) signal, GPIO (General-Purpose Input / Output) signal, SPI (Serial Peripheral Interface) signal, etc. Furthermore, the request command can also be a request command of other protocol types; for example, when the hardware interface signal is a GPIO signal, the request command is a GPIO request command. This application does not impose any special limitations on the specific types of request commands and hardware interface signals.

[0277] Step 12: Determine the multiple logical bit information corresponding to the request command.

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

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

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

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

[0282] It is important to note that, taking a BMC chip as an example and PECI signals as the hardware interface signal, in existing technologies, to achieve PECI communication between the BMC chip and components such as the CPU, the BMC chip itself needs to have a PECI controller hardware logic design, resulting in high design costs. In other words, in existing technologies, to generate PECI signals on the BMC chip, the hardware logic design of the PECI controller must be implemented on the BMC chip beforehand. However, in this application, only a first operating system is needed to generate PECI signals on the BMC chip, eliminating the need to implement the PECI controller hardware logic design on the BMC chip, thereby reducing the design difficulty and cost of the BMC chip.

[0283] Based on the content of steps 11 to 13, in this embodiment, the hardware interface signal corresponding to the request command is generated by the first operating system. First, the request command is obtained through the first operating system, then multiple logical bit information corresponding to the request command is determined, and finally the hardware interface signal corresponding to the request command is generated based on the multiple logical bit information and the timer.

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

[0285] Therefore, this implementation achieves the goal of generating hardware interface signals using a software system without requiring hardware logic design of the chip, thereby reducing the design difficulty of the chip and solving the technical problem of high chip design cost caused by the requirement of hardware logic design of the chip itself having a controller in the prior art.

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

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

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

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

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

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

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

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

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

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

[0296] Optionally, the first operating system can input the hardware interface signal into the voltage conversion device to obtain the target hardware interface signal output by the voltage conversion device.

[0297] Optionally, the voltage conversion device described above can be a CPLD, and the CPLD can be connected to the target device, wherein the target device can be the CPU in a server.

[0298] It should be noted that, in addition to being used to replace the PECI interface to generate PECI signals, the above-mentioned services can also be applied to other hardware interfaces.

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

[0300] In an optional implementation, the services running on the first operating system may include, but are not limited to, serial port switching services. This implementation provides a serial port switching process, which includes the following steps: Step 21: If the second operating system detects that it has received a serial port switching command, the second operating system sends the serial port switching command to the first operating system.

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

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

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

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

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

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

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

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

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

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

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

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

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

[0314] After obtaining the device corresponding to the serial port number, the first operating system can map the target serial port to the target output interface of the chip using the device's serial port address. After mapping the device's serial port address to the target output interface, the device can be accessed through the target output interface.

[0315] It should be noted that the serial port switching commands and parsing rules can be set according to the model of the chip used and the types of the first and second operating systems.

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

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

[0318] When the user issues a serial port switching command, the first operating system (RTOS) selects one of the three different memory segments mapped by the UART and exchanges the data of one of the memory segments with the client to achieve the purpose of simulating the CPLD hardware serial port switching circuit.

[0319] It should be noted that if the serial ports of different devices cannot be distinguished, developers will not be able to accurately locate which device's serial port is faulty during maintenance. Therefore, serial port switching is required to locate the abnormal problem.

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

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

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

[0323] The execution result of the serial port switching command is received by the second operating system. The execution result is sent from the first operating system to the second operating system and is one of the following: serial port switching successful or serial port switching failed.

[0324] After the first operating system switches the serial port, it obtains the execution result of the serial port switching command and then feeds the execution result of the serial port switching command back to the second operating system to inform the second operating system whether the serial port switch was successful or failed.

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

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

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

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

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

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

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

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

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

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

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

[0336] For the conditional triggering method in the triggering mode, the matching degree between the current operation business and the first operating system can, but is not limited to, indicate whether the operation business generated on the processor is suitable to be processed by the first operating system. By assigning suitable operation businesses to the first operating system for processing, the reasonable allocation of operation businesses is achieved, and the processing efficiency of operation businesses is also improved.

[0337] In this embodiment, the first operating system can be controlled to run based on the processor in the following ways, but not limited to: detecting the service information of the current operation service generated on the processor; and controlling the first operating system to run the current operation service based on the processor when the matching degree between the service information and the first operating system is higher than the matching degree threshold.

[0338] Optionally, in this embodiment, the matching degree between the operation service and the first operating system can be represented by, but is not limited to, the matching degree between the operation service's business information and the first operating system. The business information can be, but is not limited to, any dimension with processing requirements, such as: business response speed, business resource utilization, business coupling, business importance, etc.

[0339] Optionally, in this embodiment, a matching degree between the service information and the first operating system exceeding a matching degree threshold indicates that the service operation is suitable for running on the first operating system. The matching degree threshold can be, but is not limited to, dynamically adjusted based on the current resource usage or operational requirements of the first operating system. This makes the first operating system more adaptable and flexible.

[0340] In this embodiment, service information of the current operation generated on the processor can be detected, but is not limited to, in the following ways: detecting the target response speed and / or target resource consumption of the current operation, wherein the service information includes: target response speed and / or resource consumption, the target response speed being the response speed that the processor needs to achieve for the current operation, and the target resource consumption being the amount of resources that the processor needs to provide for the current operation; if the target response speed is less than or equal to a speed threshold, and / or the target resource consumption is less than or equal to a consumption threshold, determining that the matching degree between the service information and the first operating system is higher than the matching degree threshold.

[0341] Optionally, in this embodiment, the service information may include, but is not limited to,: target response speed, and / or resource consumption. The target response speed is the response speed that the current operation service requires the processor to achieve, and the target resource consumption is the amount of resources that the current operation service requires the processor to provide. The current operation service's requirement for processor response speed can be considered separately, or the current operation service's requirement for available resources on the processor can be considered separately. Alternatively, both can be considered together when allocating resources for the current operation service.

[0342] In an optional implementation, operating services and processing resources may be allocated to each operating system in the following ways, but are not limited to: A set of services to be allocated is assigned to the corresponding operating system in the embedded system according to the dynamic resource allocation rules. The dynamic resource allocation rules include dynamic resource allocation based on at least one of the following: service response speed, service resource utilization rate, service coupling degree, and service importance. The embedded system includes a first operating system and a second operating system, which run on a processor. The response speed of the first operating system is higher than that of the second operating system. Determine the resource allocation result corresponding to the group of services to be allocated, wherein the resource allocation result is used to indicate the processing resources of the processor corresponding to each service to be allocated in the group of services to be allocated, and the processing resources of the processor include processor cores; Based on the operating system corresponding to each service to be assigned and the resource allocation result, the processing resources of the processor are allocated to the first operating system and the second operating system.

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

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

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

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

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

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

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

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

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

[0352] Optionally, the above process also includes: generating a rule structure by reading the rule configuration file, wherein the rule structure is used to record the dynamic allocation rules of resources.

[0353] Dynamic resource allocation rules can be configured based on rule configuration files. By reading the rule configuration file, a rule structure can be generated to record the dynamic resource allocation rules. Here, the rule configuration file can be a load balancing strategy file (payload_balance.config). The load balancing strategy file can be used to configure the classification methods for various running services (or processes), the evaluation principles for real-time levels, etc. Different parameters can be configured in the load balancing strategy file to define the dynamic resource allocation rules. An example of a load balancing strategy configuration file is as follows: classification kinds = 2 / / A value of 1 indicates that processes are classified according to attributes such as importance and unimportance; otherwise, processes are classified according to a preset classification method (such as real-time and non-real-time). real-time grade evaluation=2 / / A value of 1 indicates that the average CPU utilization rate within the past statistical minutes is used as the principle for evaluating the real-time grade of the process; otherwise, the preset priority is used as the principle for evaluating the real-time grade of the process. statistic minutes = 5 / / This represents the statistical time (in minutes) for the average utilization rate of each process. It is valid when the real-time grade evaluation is 1.

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

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

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

[0357] This embodiment demonstrates how reading the rule configuration file generates a rule structure to record dynamic resource allocation rules, thus improving the convenience of information configuration.

[0358] Optionally, the above process further includes: obtaining a rule update configuration file through the external interface of the second operating system, wherein the rule update configuration file is used to update the configured dynamic resource allocation rules; and updating the rule structure using the rule update configuration file to update the dynamic resource allocation rules recorded in the rule structure.

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

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

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

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

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

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

[0365] Optionally, but not limited to, a set of services to be allocated may be assigned to the corresponding operating system in the embedded system according to the resource dynamic allocation rules in the following ways: assigning the services to be allocated in the set of services whose service response speed requirement is greater than or equal to the set response speed threshold to the first operating system, and assigning the services to be allocated in the set of services whose service response speed requirement is less than the set response speed threshold to the second operating system.

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

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

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

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

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

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

[0372] Optionally, but not limited to, a set of services to be allocated may be assigned to the corresponding operating system in the embedded system according to the resource dynamic allocation rules in the following ways: assigning the services to be allocated with a service resource occupancy rate less than a first occupancy rate threshold to the first operating system, and assigning the services to be allocated with a service resource occupancy rate greater than or equal to the first occupancy rate threshold to the second operating system.

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

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

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

[0376] Optionally, but not limited to, a set of services to be allocated may be assigned to the corresponding operating system in the embedded system according to the dynamic resource allocation rules using at least one of the following methods: The services to be assigned from a group of services to be assigned that have a service coupling degree with the already assigned services of the first operating system that is greater than or equal to a first coupling degree threshold are assigned to the first operating system. The services to be assigned from a group of services to be assigned that have a service coupling degree with the already assigned services of the second operating system that is greater than or equal to the second coupling degree threshold are assigned to the second operating system.

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

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

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

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

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

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

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

[0384] Optionally, but not limited to, a set of services to be allocated can be assigned to the corresponding operating system in the embedded system according to the dynamic resource allocation rules in the following ways: A set of pending business services containing sensitive information is assigned to a target operating system, wherein the target operating system is the operating system with low interaction frequency with the user among the first operating system and the second operating system.

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

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

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

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

[0389] Optionally, but not limited to, the resource allocation results corresponding to a set of services to be allocated can be determined in the following ways: Based on the allocation results of a set of pending services, and combined with the resource utilization of the first operating system and the resource utilization of the second operating system, a mapping table between pending services and processor processing resources is generated.

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

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

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

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

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

[0395] Optionally, but not limited to, the processor's processing resources may be allocated to the first operating system and the second operating system based on the operating system corresponding to each service to be allocated and the resource allocation result: if it is determined from the resource allocation result that there is a corresponding service to be allocated among the unallocated processing resources of the processor, 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.

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

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

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

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

[0400] After the primary operating system finishes running, it can be controlled to enter a hibernation state. For example, the primary operating system can be controlled to hibernate after it finishes running.

[0401] The end of the first operating system's operation can be the end of the running cycle, the completion of the wake-up request processing, or the completion of the current operation's business processing.

[0402] After the first operating system goes into hibernation, the second operating system can occupy the processor cores allocated to the first operating system, thereby improving resource utilization. For example, after controlling the first operating system to hibernate after its operation ends, the second operating system is notified to allow the use of the processor cores used by the first operating system. The second operating system is used to add the target processor core used by the first operating system to the scheduling resource pool of the second operating system during the hibernation period of the first operating system. The scheduling resource pool includes other processors besides the target processor core.

[0403] Optionally, in this embodiment, the method of notifying the second operating system to use the processor core used by the first operating system may include, but is not limited to, sending an interrupt request to the second operating system. After the first operating system goes into sleep mode, it sends an interrupt request to the second operating system to notify it to use the processor core used by the first operating system. The second operating system responds to the interrupt request by adding the target processor core used by the first operating system to the scheduling resource pool for scheduling and use.

[0404] In one exemplary embodiment, the operation services executed on the second operating system can be monitored, but are not limited to. If an abnormal operation service is detected, the first operating system can take over the operation of the abnormal operation service, thereby avoiding the impact of abnormal operation service operation on the entire processing process and improving the success rate and efficiency of service operation. For example, monitoring the operation services executed on the second operating system; if an abnormal operation service is detected among the operation services executed on the second operating system, the first operating system can take over the abnormal operation service.

[0405] Optionally, in this embodiment, the processor or the first operating system may monitor the second operating system, and any abnormal operations detected (such as operations where the business thread is dead) may be taken over by the first operating system. Alternatively, the detected abnormal operations may be assigned to an operating system with a high degree of compatibility with the abnormal operation among multiple operating systems.

[0406] Optionally, in this embodiment, the monitoring of operational services executed on the second operating system can include, but is not limited to, monitoring of heartbeat signals, monitoring of service logs, etc. For example, if an abnormal log is detected, it is determined that the operational service is abnormal.

[0407] In one exemplary embodiment, the operation services executed on the second operating system may be monitored in the following manner, but not limited to: receiving a heartbeat signal for each operation service executed on the second operating system; and identifying operation services whose heartbeat signal frequency does not conform to the corresponding target frequency as abnormal operation services.

[0408] Optionally, in this embodiment, each operation service executed on the second operating system generates a heartbeat signal. The heartbeat signals of different operation services have different frequencies. The heartbeat signal of each operation service executed on the second operating system is connected to the monitoring party of the operation service, such as the processor or the first operating system. The frequency of the connected heartbeat signal is compared with the target frequency corresponding to the operation service. Operation services whose heartbeat signal frequency does not conform to the corresponding target frequency are taken over as abnormal operation services.

[0409] Optionally, in this embodiment, whether the frequency of the heartbeat signal matches the corresponding target frequency can be determined by comparing whether the two are completely identical. If they are completely identical, it is determined to be consistent; if they are not completely identical, it is determined to be inconsistent. Alternatively, a certain error range can be given, and whether the frequency of the heartbeat signal falls within the error range of the target frequency can be determined to be consistent. If it falls within the error range, it is determined to be consistent; if it does not fall within the error range, it is determined to be inconsistent.

[0410] In one exemplary embodiment, after taking over the abnormal operation service through the first operating system, the abnormal operation service on the second operating system may be restarted in the following manner, but is not limited to: sending a restart command to the second operating system, wherein the restart command is used to instruct the abnormal operation service to be restarted.

[0411] Optionally, in this embodiment, the restart command is used to instruct the restart of the abnormal operation service. After receiving the restart command, the second operating system can initialize the abnormal operation service until it is restarted.

[0412] Optionally, in this embodiment, after the abnormal operation service on the second operating system restarts, the first operating system can return the abnormal operation service it has taken over to the second operating system. The first operating system can save the current running state of the abnormal operation service to shared memory and send an interrupt request to the second operating system. The second operating system reads the current running state of the abnormal operation service from the shared memory and loads it into the abnormal operation service it is running, so that the abnormal operation service can continue to run and improve the service operation efficiency.

[0413] Figure 10 This is a schematic diagram of a system anomaly monitoring process according to an embodiment of this application, such as... Figure 10 As shown, the first operating system receives heartbeat signals from the operational services executed on the second operating system. If it detects an abnormal operational service whose heartbeat frequency does not match the target frequency, the first operating system takes over and continues executing the abnormal operational service on the second operating system. Furthermore, the first operating system sends a restart command to the second operating system, enabling the second operating system to restart the abnormal operational service.

[0414] In one exemplary embodiment, a dual system may be started, but is not limited to, by booting a first operating system or booting a second operating system.

[0415] Optionally, in this embodiment, the first operating system is booted first, and then the second operating system is booted. The first operating system may be, but is not limited to, an operating system with a faster and simpler boot process. During the boot process of the second operating system, the first operating system may perform some urgent or helpful operations to boot the second operating system, thereby improving the boot efficiency of the operating system or improving the processing efficiency of the operations.

[0416] Optionally, in this embodiment, the first operating system and the second operating system may be started sequentially, but not limited to. The first operating system may be started faster than the second operating system, and the conditions required for the first operating system to start are simpler than those required for the second operating system to start. After the first operating system starts first, services that meet the conditions required for the second operating system to start or can speed up the startup of the second operating system can be run, thereby enabling multiple systems to start and run services more efficiently and quickly.

[0417] For example, after the first operating system boots up, it can run services that can control the chip environment parameters to meet the boot requirements of the second operating system (such as fan operation, parameter control, etc.), so that the chip environment parameters can quickly meet the boot and running environment of the second operating system, thereby improving the boot and running efficiency of the operating system.

[0418] Optionally, in this embodiment, the first operating system may be booted by, but is not limited to, its own bootloader, and the second operating system may be booted by, but is not limited to, its own bootloader. Alternatively, both may be booted sequentially by the same bootloader.

[0419] In one exemplary embodiment, the first operating system may be booted up in the following manner, but is not limited to: the chip is powered on, and the processor wakes up the first processor core allocated to the first operating system in the processor; the first processor core executes the boot program of the first operating system to boot the first operating system.

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

[0421] Optionally, in this embodiment, the bootloader of the first operating system may be, but is not limited to, stored in a specific storage space on the chip specifically for booting the first operating system.

[0422] Optionally, in this embodiment, the first processor core of the first operating system may be used, but is not limited to, to execute the boot program of the first operating system, and may be used, but is not limited to, to start the first operating system by executing the boot program of the first operating system.

[0423] In one exemplary embodiment, the first operating system may be booted by executing a bootloader of the first operating system through the first processor core in the following manner, but not limited to: executing a secondary program loader through the first processor core, wherein the bootloader of the first operating system includes the secondary program loader; and loading the first operating system through the secondary program loader.

[0424] Optionally, in this embodiment, the bootloader of the first operating system may include, but is not limited to, the second program loader, and the first processor core may load the first operating system by executing the second program loader (SPL).

[0425] In one exemplary embodiment, the second operating system may be booted in the following manner, but is not limited to: waking up the second processor core allocated to the second operating system through the secondary program loader; and booting the second operating system by executing the boot program of the second operating system through the second processor core.

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

[0427] Optionally, in this embodiment, the second processor core of the second operating system can be woken up by, but is not limited to, using a secondary program loader. For example, after the first operating system is loaded using the secondary program loader, the second processor core of the second operating system can be woken up by, but is not limited to, using the secondary program loader. Alternatively, during the process of loading the first operating system using the secondary program loader, the second processor core of the second operating system can be woken up by, but is not limited to, using the secondary program loader.

[0428] Optionally, in this embodiment, the bootloader of the second operating system may be executed using the second processor core to boot the second operating system.

[0429] In one exemplary embodiment, the second operating system may be booted by executing a bootloader of the second operating system through the second processor core in the following manner, but not limited to: executing a generic bootloader through the second processor core, wherein the bootloader of the second operating system includes the generic bootloader; and loading the second operating system through the generic bootloader.

[0430] Optionally, in this embodiment, the second processor core may, but is not limited to, load the second operating system by executing a universal bootloader, which may, but is not limited to, include U-Boot (Universal Boot Loader).

[0431] In one exemplary embodiment, the secondary program loader may be executed via the first processor core in the following manner, but not limited to: performing a security boot check on the code of the secondary program loader via the boot memory on the chip; and executing the secondary program loader via the first processor core if the check result is normal.

[0432] Optionally, in this embodiment, the bootloader of the operating system may include, but is not limited to, a secondary program loader, and may include, but is not limited to, the bootloader of the operating system as the aforementioned boot memory. The code of the secondary program loader included in the bootloader of the operating system can be verified through the boot memory. For example, the secondary program loader of the first operating system (which may be, but is not limited to, BootROM) may be obtained based on the bootloader of the first operating system (the bootloader may be, but is not limited to, BootROM), and the code of the secondary program loader may be verified based on the boot memory of the first operating system (which may be, but is not limited to, BootROM).

[0433] Optionally, in this embodiment, the process of the boot memory performing a security boot check on the code of the secondary program loader may include, but is not limited to, the following: the boot memory reads the code of the secondary program loader and the verification code, performs an operation on the code of the secondary program loader using an agreed operation method (such as hash operation) to obtain an operation value, and then compares the operation value with the read verification code. If the two match, the check result is normal; if the two do not match, the check result is abnormal.

[0434] Optionally, in this embodiment, the secondary program loader can also perform a security boot check on the code of the general boot loader. The secondary program loader reads the code of the general boot loader and the verification code, and performs an operation on the code of the general boot loader using an agreed-upon calculation method (such as hash operation, which can be the same as or different from the calculation method used by the boot memory to check the secondary program loader). The calculated value is then compared with the read verification code. If they match, the check result is normal; if they do not match, the check result is abnormal. If the check result is normal, the second operating system is then loaded through the general boot loader.

[0435] In one exemplary embodiment, an example of booting a first operating system and a second operating system is provided. Taking a first processor core as CPU-0 and second processor cores as CPU-1 to CPU-N as an example, the first and second operating systems can be booted in the following ways, but not limited to: the chip is powered on; the first processor core CPU-0 of the first operating system in the processor is woken up; the boot program of the first operating system is executed using the first processor core CPU-0, which may be, but is not limited to, a secondary program loader; a security boot check is performed on the code of the secondary program loader through the boot memory on the chip (which may be, but is not limited to, BootROM); if the check result is normal, the first operating system is loaded by the secondary program loader (which may be, but is not limited to, SPL) executed by the first processor core; the second processor cores CPU-1 to CPU-N of the second operating system are woken up by the secondary program loader; and the second operating system is loaded by the general boot loader (which may be, but is not limited to, U-Boot) executed by the second processor core.

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

[0437] This embodiment also provides an embedded system for implementing the above-described operating system operation control method. Figure 11 This is a schematic diagram of an embedded system according to an embodiment of this application. Figure 1 ,like Figure 11As shown, 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, and the first bus 1106 is configured in a multi-master multi-slave mode, while the second bus 1108 is configured in a single-master multi-slave mode. At least two operating systems run on the processor 1102. At least two operating systems communicate with each other through the first bus 1106. At least two operating systems control the hardware controller through the second bus 1108.

[0438] The aforementioned chip can be a BMC chip; the aforementioned processor can be a multi-core processor; the aforementioned hardware controller can be used to control external devices connected to the corresponding external interface; the aforementioned first bus is configured in a multi-master multi-slave mode, which can be a bus used for communication between multiple processor cores of the processor, such as AHB (Advanced High Performance Bus); the aforementioned second bus is configured in a one-master multi-slave mode, which can be a bus used by the processor to control the hardware controller, such as APB (Advanced Peripheral Bus); the bandwidth of the first bus is higher than the bandwidth of the second bus.

[0439] An embedded system may include at least two operating systems that run on a processor, and the processor’s processing resources are dynamically allocated to the at least two operating systems. The processor’s processing resources include the processor core. The at least two operating systems communicate with each other through a first bus and control the hardware controller through a second bus.

[0440] Optionally, the hardware controller may include one or more of the following chip peripheral controllers, including but not limited to: 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 (Watchdog Timer), Virtual UART, Super I / O, SGPIO (Serial General Purpose Input / Output), PWM (Pulse Width Modulation), FanTach, Timer, PECI (Platform Environment Control Interface), Mailbox, and may also include other types of controllers. External interfaces may include one or more of the above controllers, including but not limited to those corresponding to any of the aforementioned controllers.

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

[0442] The aforementioned cores and controllers are interconnected via a second bus, enabling interaction between the cores and controllers. Simultaneously, the ARM cores are connected to a first bus (e.g., via an AXI (Advanced eXtensible Interface) bridge), and communication between cores is achieved through this first bus. Furthermore, the SOC submodules also implement interconnection between the first and second buses (e.g., through bridge conversion), thus providing a physical path for the SOC submodules to access peripherals on the second bus.

[0443] The DDR4 controller can be connected to other components or devices through the DDR4 PHY (Physical Layer) interface, the MAC controller can be connected to other components or devices through the RGMII (Reduced Gigabit Media Independent Interface), the SD card / eMMC controller can be connected to other components or devices through the SD interface, and the PCIe RC controller can be connected to other components or devices through the PCIe PHY interface.

[0444] The BMC out-of-band submodules mainly include controllers for chip peripherals such as PWM, GPIO, FanTech (fan speed control), and mailbox. These controllers enable out-of-band management functions such as PECI communication with the BMC (e.g., using GPIO to simulate PECI) and fan control. Figure 12 It can be seen that the BMC out-of-band submodule can, but is not limited to, interact with the SOC submodule through the second bus.

[0445] The BMC chip interconnects its on-chip ARM core, memory units, and controller hardware resources via a first bus and a second bus. Dynamic balancing of processor resources primarily involves the scheduling of ARM core resources within the BMC chip, while inter-core communication refers to communication between ARM cores. Taking Linux preemption of the RTOS system kernel as an example, the Linux system first sends an inter-core interrupt (interrupt number 9) to core 1 via the on-chip first bus from one of cores 2 through N. If the RTOS system is idle and allows preemption, core 1 responds with an inter-core interrupt (interrupt number 10) via the first bus and releases the peripheral controller resources currently mapped to core 1 (e.g., PWM / PECI). Upon receiving inter-core interrupt 10, the Linux system initiates a preemption process, adding core 1 to the Linux SMP scheduler and simultaneously gaining control of the PWM / PECI peripheral, which can then be controlled via the second bus.

[0446] On one hand, at least two operating systems are included, namely a first operating system and a second operating system. The chip loads communication values ​​onto a first bus, and the first bus sends communication signals carrying communication values ​​to the communication register corresponding to the second operating system to realize communication between the first operating system and the second operating system. The communication values ​​are used to indicate the communication content between the first operating system and the second operating system.

[0447] On the other hand, the chip loads the control value onto the second bus, and the second bus sends the control signal carrying the control value to the register corresponding to the hardware controller, so as to realize the operating system's control over the hardware controller. The control value is used to indicate the control content of the operating system on the hardware controller.

[0448] The operating system controls the hardware controllers by accessing (e.g., performing read and write operations) the registers of each hardware controller. The operating system can access these registers by reading or writing to their addresses, but is not limited to this. These register addresses can be uniquely determined during chip design. For example, by writing a specific value (i.e., the communication register or the register corresponding to the hardware controller) to a specific address, the operating system can achieve a specific function (such as communication between operating systems or control of the hardware controller). In other words, different functions correspond to different control values. The chip maintains the correspondence between the hardware controller's functions and the control values; for example, a control value of 00 indicates the air conditioner accelerates by one level, and a control value of 01 indicates the air conditioner decelerates by one level, and so on.

[0449] Communication and control interactions between different operating systems, and between the operating system and the hardware controller, can be achieved, but are not limited to, through a bus. The read / write operations of the operating system on the registers of each hardware controller are ultimately translated into control signals from the first bus (or second bus) to that hardware controller. This conversion and the control process of the first bus (or second bus) on the hardware controller can be, but are not limited to, automatically implemented by the internal hardware of the chip. The implementation process follows the bus specification. During the operation of the first bus (or second bus), it can transmit physical signals related to the bus protocol, and also transmit valid data to each hardware controller through its physical data channel.

[0450] The first bus system can consist of, but is not limited to, three parts: a master module, slave modules, and infrastructure. All transmissions on the first bus are initiated by the master module, with responses from the slave modules. The infrastructure can include, but is not limited to, an arbiter, multiplexers from master to slave modules, multiplexers from slave to master modules, a decoder, dummy slave modules, and dummy master modules. In the multi-master, multi-slave mode of the first bus, the master first sends a message request to the arbiter. The arbiter decides when to grant the master bus access. After gaining access, the master sends data and control signals to the arbiter. The arbiter uses address resolution to determine the corresponding slave path and then sends the request to the corresponding destination. Similarly, the response data is parsed by the decoder and returned to the corresponding master. This multiplexing mechanism enables many-to-many access.

[0451] In a master-slave configuration for the second bus, the second bus can be connected to the first bus system. A bridge connects the two bus systems, facilitating transaction translation. In this configuration, the bridge acts as the master, and all other peripheral devices (i.e., hardware controllers) are slaves. Data requests can only be sent from the master to the slave. Upon receiving a request, the slave returns the corresponding response data to the master. This process enables one-to-many access, and the access does not require arbitration or decoder parsing operations on the first bus.

[0452] The embedded system is configured with a first bus in a multi-master, multi-slave mode and a second bus in a one-master, multi-slave mode. The first bus in the multi-master, multi-slave mode can use relatively more complex logic circuits and bus protocols to complete the communication between systems more efficiently. The second bus in the one-master, multi-slave mode can use relatively simple logic circuits and bus protocols to complete the system's control of the hardware controller while reducing the complexity of the structure and the power consumption of the entire embedded system. The configuration and cooperation of multiple modes on the bus can further improve the operating performance of the embedded system.

[0453] In the aforementioned embedded system, the first and second operating systems run on the processor and communicate with each other and control the hardware controller via buses with different functions. Since both the first and second operating systems run on the same processor, the addition and deployment of hardware components are avoided, reducing system costs. Furthermore, processor resources are used efficiently to support inter-system operation. Therefore, the technical problem of low operating system efficiency can be solved, achieving the technical effect of improving operating system efficiency.

[0454] In one exemplary embodiment, at least two operating systems include a first operating system and a second operating system, wherein the first operating system controls the target hardware controller to run the target operation service based on the processor; the first operating system releases the target hardware controller through a second bus when the target operation service reaches the target service state; and the second operating system controls the target hardware controller to run the target operation service through the second bus.

[0455] Optionally, in this embodiment, the target operation service is run by the target hardware controller, and the first operating system controls the target hardware controller based on the processor. The second operating system can take over the target operation service by taking over the target hardware controller.

[0456] Optionally, in this embodiment, the takeover process of the target operation service is similar to that in the previous embodiments, and will not be described in detail here.

[0457] When the target operation reaches the target service state, the first operating system writes a specific value (i.e., the aforementioned control value) corresponding to the target hardware controller to disable the target hardware controller. The specific value to be written is automatically loaded into the data channel of the second bus by the chip hardware, ultimately realizing hardware control of the hardware controller (i.e., implementing the release operation).

[0458] The second operating system writes specific values ​​corresponding to the target operation service (i.e., the aforementioned control values) to the registers of the target hardware controller to achieve the purpose of controlling the target hardware controller to run the target operation service. The specific values ​​that need to be written are automatically loaded into the data channel of the second bus by the chip hardware, and finally the hardware controller is controlled in hardware (i.e., the target operation service is run).

[0459] In one exemplary embodiment, the second operating system sends a first interrupt request to the first operating system via the first bus, wherein the first interrupt request is used to request takeover of the target hardware controller; the first operating system responds to the first interrupt request and releases the target hardware controller via the second bus; or, the first operating system releases the target hardware controller via the second bus when the service attributes of the target operation service reach the target service attributes.

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

[0461] Optionally, in this embodiment, the process of releasing and taking over the target hardware controller is similar to that in the previous embodiments, and will not be described in detail here.

[0462] The second operating system writes a specific value corresponding to the first interrupt request (i.e., the aforementioned communication value) into the interrupt register to send the first interrupt request to the first operating system. The specific value to be written is automatically loaded into the data channel of the first bus by the chip hardware, ultimately implementing the interrupt request function in hardware.

[0463] In one exemplary embodiment, the first operating system responds to a first interrupt request to determine whether the second operating system should take over the target hardware controller; if the second operating system takes over the target hardware controller, the first operating system releases the target hardware controller via the second bus.

[0464] Optionally, in this embodiment, the first operating system can determine whether the second operating system should take over the target hardware controller. The determination process is similar to that in the previous embodiments and will not be described in detail here.

[0465] In one exemplary embodiment, the first operating system sends a second interrupt request to the second operating system via a first bus without the second operating system taking over the target hardware controller. The second interrupt request is used to indicate that the second operating system is refused to take over the target hardware controller.

[0466] Optionally, in this embodiment, the process by which the first operating system refuses the second operating system from taking over the target hardware controller is similar to that in the previous embodiments and will not be described in detail here.

[0467] In one exemplary embodiment, the first operating system sends a third interrupt request to the second operating system, wherein the third interrupt request is used to indicate that the first operating system has released the target hardware controller; the second operating system responds to the third interrupt request and controls the target hardware controller to run the target operation service through the second bus.

[0468] Optionally, in this embodiment, the process by which the first operating system notifies the second operating system that the target hardware controller has been released is similar to that in the previous embodiments, and will not be described in detail here.

[0469] The second operating system writes specific values ​​(i.e., the aforementioned control values) corresponding to the target operation service to the registers of the target hardware controller to achieve the purpose of controlling the target hardware controller to run the target operation service. The specific values ​​that need to be written are automatically loaded into the data channel of the second bus by the chip hardware, and finally the hardware controller is controlled in hardware.

[0470] In one exemplary embodiment, at least two operating systems include a first operating system and a second operating system, wherein the first operating system runs based on a target processor core in the processor; the first operating system releases the target processor core when it reaches the target system state; and the second operating system adds the target processor core to the scheduling resource pool of the second operating system, wherein the scheduling resource pool includes processor cores allocated to the second operating system in the processor.

[0471] Optionally, in this embodiment, the process of at least two operating systems occupying the target processor core is similar to that in the previous embodiments, and will not be described in detail here.

[0472] In one exemplary embodiment, the second operating system sends a fourth interrupt request to the first operating system via the first bus, wherein the fourth interrupt request is used to request the use of the target processor core; the first operating system responds to the fourth interrupt request and releases the target processor core; or, the first operating system releases the target processor core when the system attributes reach the target system attributes.

[0473] Optionally, in this embodiment, the second operating system may actively preempt the target processor core, and the first operating system may actively release the target processor core.

[0474] Optionally, in this embodiment, the preemption and release process of the target processor core is similar to that in the previous embodiments, and will not be described in detail here.

[0475] In one exemplary embodiment, the first operating system responds to a fourth interrupt request to determine whether the target processor core is occupied by the second operating system; if the target processor core is occupied by the second operating system, the first operating system releases the target processor core.

[0476] Optionally, in this embodiment, the first operating system can determine whether the target processor core is occupied by the second operating system. This process is similar to that in the previous embodiments and will not be described in detail here.

[0477] In one exemplary embodiment, the first operating system sends a fifth interrupt request to the second operating system via a first bus without the second operating system occupying the target processor core. The fifth interrupt request is used to indicate that the second operating system is refused access to the target processor core.

[0478] Optionally, in this embodiment, the process by which the first operating system refuses the second operating system from occupying the target processor core is similar to that in the previous embodiments and will not be described in detail here.

[0479] In one exemplary embodiment, the first operating system sends a sixth interrupt request to the second operating system, wherein the sixth interrupt request is used to indicate that the first operating system has released the target processor core; the second operating system responds to the sixth interrupt request by adding the target processor core to the scheduling resource pool.

[0480] Optionally, in this embodiment, the process by which the first operating system notifies the second operating system that the target processor core has been released is similar to that in the previous embodiments, and will not be described in detail here.

[0481] In one exemplary embodiment, at least two operating systems include a first operating system and a second operating system, wherein a target processor core in the processor has been added to the scheduling resource pool of the second operating system, wherein the scheduling resource pool includes processor cores in the processor allocated to the second operating system; the second operating system releases the target processor core when the first operating system is woken up; and the first operating system runs based on the target processor core.

[0482] Optionally, in this embodiment, the process of the first operating system waking up and using the target processor core is similar to that in the previous embodiments, and will not be described in detail here.

[0483] In one exemplary embodiment, the second operating system releases the target processor core when it detects that the first operating system has been woken up; or, the first operating system sends a seventh interrupt request to the second operating system when it is woken up, wherein the seventh interrupt request is used to request the second operating system to release the target processor core; the second operating system releases the target processor core in response to the seventh interrupt request.

[0484] Optionally, in this embodiment, the second operating system actively releases the target processor core when the first operating system wakes up, or the first operating system actively requests it to release the target processor core. This process is similar to that in the previous embodiments and will not be described in detail here.

[0485] In one exemplary embodiment, at least two operating systems include a first operating system and a second operating system. The chip also includes a storage space. The at least two operating systems control the storage space through a first bus. The first operating system generates business data based on the processor's operation. The first operating system stores the business data in the storage space through the first bus and sends an eighth interrupt request to the second operating system through the first bus. The eighth interrupt request is used to request the second operating system to read the business data from the storage space. The second operating system responds to the eighth interrupt request and reads the business data from the storage space.

[0486] Optionally, in this embodiment, the first operating system and the second operating system may, but are not limited to, realize the interaction of inter-system business data through the transmission of storage space and interrupt requests. The interaction process of inter-system business data is similar to that in the previous embodiment and will not be described in detail here.

[0487] The first operating system writes specific values ​​to a specific address of the storage controller to store the business data in the storage space. The specific values ​​to be written are automatically loaded into the data channel of the first bus by the chip hardware, ultimately realizing the control of the storage controller and the storage of the business data in hardware (i.e., realizing the transmission of valid data through its physical data channel).

[0488] In one exemplary embodiment, the first operating system runs periodically based on the processor; or, the first operating system runs based on the processor in response to a received wake-up request; or, the first operating system runs based on the processor based on the matching degree between the current operation service generated on the processor and the first operating system.

[0489] Optionally, in this embodiment, the operating mechanism of the first operating system is similar to that in the previous embodiments, and will not be described in detail here.

[0490] In one exemplary embodiment, the first operating system hibernates after it finishes running; during the hibernation period of the first operating system, the second operating system adds the target processor core used by the first operating system to the scheduling resource pool of the second operating system, wherein the scheduling resource pool includes processors other than the target processor core.

[0491] Optionally, in this embodiment, the process of the second operating system occupying the target processor core during the hibernation period of the first operating system is similar to that in the previous embodiments, and will not be described in detail here.

[0492] In one exemplary embodiment, at least two operating systems communicate via a communication protocol deployed on a first bus; or, at least two operating systems communicate via a first bus, a second bus, and a communication hardware controller in a hardware controller.

[0493] Optionally, in this embodiment, at least two operating systems may communicate through a communication protocol deployed on the first bus, that is, they may implement inter-core communication through software, but are not limited to this.

[0494] Optionally, in this embodiment, at least two operating systems can also communicate through, but are not limited to, a first bus, a second bus, and a communication hardware controller in the hardware controller, that is, they can implement inter-core communication through hardware, but are not limited to.

[0495] In one exemplary embodiment, at least two operating systems communicate by sending inter-processor interrupt requests via a first bus; or, one of the at least two operating systems sends a system interrupt request to the first bus; the first bus forwards the system interrupt request to a second bus; the second bus sends the system interrupt request to the mailbox hardware module controlled by the communication hardware controller; and the mailbox hardware module sends the system interrupt request to the other of the at least two operating systems via the second bus and the first bus.

[0496] Optionally, in this embodiment, the preemption and release of processor resources between different operating systems, as well as the interaction of business data, can be accomplished, but is not limited to, through inter-core interrupts, such as SGI (Software Generated Interrupt, inter-core interrupt in Linux system). An operating system can send a resource preemption request (e.g., kernel preemption request) or a resource release request (e.g., kernel release request) to another operating system through IPI (Inter-Processor Interrupt) to request the preemption or release of processing resources.

[0497] Optionally, in this embodiment, inter-core communication can also be achieved through a mailbox channel connected to the mailbox controller in the out-of-band submodule, but not limited to this.

[0498] In one exemplary embodiment, at least two operating systems include a first operating system and a second operating system, wherein the first operating system monitors the operational services executed on the second operating system through a first bus; when there are abnormal operational services among the operational services executed by the first operating system on the second operating system, the abnormal operational services are taken over through the first bus.

[0499] Optionally, in this embodiment, the monitoring process of abnormal operation services on the second operating system by the first operating system is similar to that in the previous embodiments, and will not be described in detail here.

[0500] The second operating system writes values ​​to a specific address of the storage controller at a certain frequency. The first operating system reads this specific address of the storage controller to monitor the operations executed on the second operating system. The specific address of the storage controller to be read is automatically loaded into the address channel of the first bus by the chip hardware, enabling hardware-based reading of the specific address of the storage controller. The read value is returned to the first operating system from the data channel of the first bus in hardware form, ultimately achieving the monitoring of the operations executed on the second operating system.

[0501] The first operating system can take over the abnormal operation service by controlling the hardware controller corresponding to the abnormal operation service. The first operating system writes specific values ​​to the registers of the hardware controller for the abnormal operation service to control the hardware controller. The specific values ​​to be written are automatically loaded into the data channel of the first bus by the chip hardware, ultimately achieving hardware control of the hardware controller and the takeover of the abnormal operation service.

[0502] In an exemplary embodiment, the first operating system receives heartbeat signals from operational services executed on the second operating system via a first bus; the first operating system takes over operational services whose heartbeat signal frequency does not conform to the corresponding target frequency as abnormal operational services via the first bus.

[0503] Optionally, in this embodiment, the process by which the first operating system monitors abnormal operation services on the second operating system by monitoring the frequency of the heartbeat signal is similar to that in the previous embodiments, and will not be described again here.

[0504] The first operating system reads the value of a specific address of the memory controller to receive heartbeat signals from the operational services executed on the second operating system. The specific address of the memory controller to be read is automatically loaded into the address channel of the first bus by the chip hardware, thus implementing the reading of the specific address of the memory controller in hardware. The read value is returned to the first operating system in hardware form from the data channel of the first bus, ultimately achieving the reception of heartbeat signals from the operational services executed on the second operating system.

[0505] In one exemplary embodiment, after taking over abnormal operation services, the first operating system sends a restart command to the second operating system via a first bus, wherein the restart command is used to instruct the abnormal operation services to be restarted.

[0506] Optionally, in this embodiment, the restart process of the abnormal operation service after the first operating system takes over the abnormal operation service on the second operating system is similar to that in the previous embodiments, and will not be described in detail here.

[0507] After taking over the abnormal operation service, the first operating system writes a specific value to a specific address on the storage controller to restart the abnormal operation service of the second operating system. The specific value to be written is automatically loaded into the data channel of the first bus by the chip hardware, updating the value at the specific address of the storage controller in hardware. The second operating system reads and parses the specific value, and then restarts the corresponding abnormal operation service.

[0508] In one exemplary embodiment, the chip further includes a memory storing a boot module. After the chip is powered on, the boot module runs to boot one of at least two operating systems and boots the other operating systems among the at least two operating systems.

[0509] Optionally, in this embodiment, the boot process of multiple operating systems is similar to that in the previous embodiments, and will not be described in detail here.

[0510] In one 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 run target operation services based on a processor. When the target operation services reach a target service state, the first operating system releases the target hardware controller via a second bus. The second operating system controls the target hardware controller to run the target operation services via the second bus. The first operating system runs based on a target processor core in the processor. When the first operating system reaches a target system state, it releases the target processor core. The second operating system adds the target processor core to its own scheduling resource pool, which includes processor cores allocated to the second operating system. The chip also includes storage space, which is controlled by the at least two operating systems via a first bus. The first operating system generates service data during processor operation. The first operating system stores 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 requests the second operating system to read service data from the storage space. The second operating system responds to the eighth interrupt request and reads service data from the storage space.

[0511] Optionally, in this embodiment, the operating systems can both take over the hardware controller and preempt the processor core. This process is similar to that in the previous embodiments and will not be described in detail here.

[0512] This embodiment also provides another embedded system for implementing the above-described operating system operation control method. The embedded system can run on the above-described 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 run on the processor. The controller is used to detect the running status of the first operating system during operation and control the processor resources used by the first operating system according to the running status.

[0513] In the aforementioned embedded system, both the first and second operating systems run on the processor. The controller detects the running status of the first operating system and controls the processor resources used by it based on that status. Since both the first and second operating systems run on the same processor, the addition and deployment of hardware components are avoided, reducing system costs. Furthermore, the controller can control the processor resources used by the operating systems during operation, thus rationally utilizing processor resources to support inter-system operation. Therefore, this solves the technical problem of low operating system efficiency and achieves the technical effect of improving operating system efficiency.

[0514] In this embodiment, the first operating system and the second operating system can be similar to those in the previous embodiments. The first operating system and the second operating system run on the processor, and the controller can be a software module running under the first operating system or the second operating system.

[0515] Optionally, in this embodiment, the controller's processing logic may be deployed on the processor, or it may be deployed on the first operating system. Alternatively, it may be divided into a first control unit and a second control unit according to their functions and deployed on the first operating system and the second operating system respectively, thereby realizing functions such as processor resource control, operation business management, and business interaction between systems.

[0516] In one exemplary embodiment, the controller is configured to: detect the service state of a target operation service run by a first operating system based on a processor, wherein the service state includes the service state; and detect the system state of the first operating system, wherein the service state includes the system state, and the first operating system runs based on a target processor core in the processor.

[0517] Optionally, in this embodiment, the controller's detection of service status and system status is similar to that in the previous embodiments, and will not be described in detail here.

[0518] In one exemplary embodiment, a controller is configured to release a target operation service when the service state is detected to be a target service state, wherein the processor resources include the target operation service; a second operating system is configured to run the target operation service; and / or, the controller is configured to release a target processor core when the system state is detected to be a target system state, wherein the processor resources include the target processor core; and the second operating system is configured to add the target processor core to the scheduling resource pool of the second operating system, wherein the scheduling resource pool includes processor cores allocated to the second operating system in the processor pool.

[0519] Optionally, in this embodiment, the process of the controller controlling the target operation service and releasing the target processor core is similar to that in the previous embodiments, and will not be described again here.

[0520] In one exemplary embodiment, the embedded system further includes: a first business interaction thread running on a first operating system, and a second business interaction thread running on a second operating system, wherein the controller is configured to determine that the detected business state is a target business state when a first interrupt request is received from the second business interaction thread to the first business interaction thread, wherein the first interrupt request is used to request takeover of the target operation business; or, the controller is configured to determine that the detected business state is a target business state when the business attributes of the target operation business reach the target business attributes.

[0521] Optionally, in this embodiment, the interaction process between operating systems can be controlled, but is not limited to, through business interaction threads deployed separately on each operating system.

[0522] Optionally, in this embodiment, the process of detecting the service status is similar to that in the previous embodiments, and will not be described in detail here.

[0523] In one exemplary embodiment, the controller is configured to: respond to a first interrupt request, determine whether a second operating system will take over the target operation service; and release the target operation service if the second operating system takes over the target operation service.

[0524] Optionally, in this embodiment, the process by which the controller determines whether the target operation service is taken over by the second operating system is similar to that in the previous embodiments, and will not be repeated here.

[0525] In one exemplary embodiment, the embedded system further includes: a first business interaction thread running on a first operating system, and a second business interaction thread running on a second operating system, wherein the first business interaction thread is configured to send a second interrupt request to the second business interaction thread when the target operation business is not taken over by the second operating system, wherein the second interrupt request is used to indicate that the second operating system is refused to take over the target operation business.

[0526] Optionally, in this embodiment, the process of refusing the second operating system from taking over the target operation services is similar to that in the previous embodiments, and will not be described in detail here.

[0527] In one exemplary embodiment, the embedded system further includes: a first service interaction thread running on a first operating system, and a second service interaction thread running on a second operating system, wherein the first service interaction thread is configured to send a third interrupt request to the second service interaction thread, wherein the third interrupt request is configured to indicate that the target hardware controller has been released; and the second operating system is configured to control the target hardware controller to run the target operation service in response to the third interrupt request.

[0528] Optionally, in this embodiment, the notification process for the released target hardware controller is similar to that in the previous embodiments, and will not be described in detail here.

[0529] In one exemplary embodiment, the embedded system further includes: a first business interaction thread running on a first operating system, and a second business interaction thread running on a second operating system, wherein the controller is configured to determine that the detected system state is the target system state when a fourth interrupt request is received from the second business interaction thread to the first business interaction thread, wherein the fourth interrupt request is used to request the occupation of the target processor core; or, the controller is configured to determine that the detected system state is the target system state when the system attributes of the first operating system reach the target system attributes.

[0530] Optionally, in this embodiment, the system status detection process is similar to that in the previous embodiments, and will not be described in detail here.

[0531] In one exemplary embodiment, the controller is configured to: respond to a fourth interrupt request, determine whether the target processor core is occupied by a second operating system; and release the target processor core if the target processor core is occupied by the second operating system.

[0532] Optionally, in this embodiment, the process by which the controller determines whether the target processor core is occupied by the second operating system is similar to that in the previous embodiments, and will not be repeated here.

[0533] In one exemplary embodiment, the embedded system further includes: a first business interaction thread running on a first operating system, and a second business interaction thread running on a second operating system, wherein the first business interaction thread is configured to send a fifth interrupt request to the second business interaction thread without the second operating system occupying the target processor core, wherein the fifth interrupt request is configured to indicate that the second operating system is refused to occupy the target processor core.

[0534] Optionally, in this embodiment, the process of denying the second operating system from occupying the target processor core is similar to that in the previous embodiments, and will not be described in detail here.

[0535] In one exemplary embodiment, the embedded system further includes: a first business interaction thread running on a first operating system, and a second business interaction thread running on a second operating system, wherein the first business interaction thread is used to send a sixth interrupt request to the second business interaction thread, wherein the sixth interrupt request is used to indicate that the first operating system has released the target processor core; and the second operating system is used to add the target processor core to the scheduling resource pool in response to the sixth interrupt request.

[0536] Optionally, in this embodiment, the notification process for releasing the target processor core is similar to that in the previous embodiments, and will not be described in detail here.

[0537] In one exemplary embodiment, the controller is further configured to: detect whether the target processor core has been released when the target processor core in the processor has been added to the scheduling resource pool of the second operating system and the first operating system is woken up and running, wherein the scheduling resource pool includes processor cores allocated to the second operating system in the processor; and run the first operating system based on the target processor core when it is detected that the second operating system has released the target processor core when the first operating system is woken up.

[0538] Optionally, in this embodiment, the operation process when the first operating system wakes up is similar to that in the previous embodiments, and will not be described again here.

[0539] In one exemplary embodiment, the embedded system further includes: a first business interaction thread running on a first operating system, and a second business interaction thread running on a second operating system, wherein the first business interaction thread is configured to send a seventh interrupt request to the second business interaction thread when it is detected that the target processor core has not been released, wherein the seventh interrupt request is configured to request the second operating system to release the target processor core; and the second operating system is configured to release the target processor core in response to the seventh interrupt request.

[0540] Optionally, in this embodiment, the negotiation process for the second operating system to release the target processor core is similar to that in the previous embodiments, and will not be described in detail here.

[0541] In one exemplary embodiment, the embedded system further includes: a first business interaction thread running on a first operating system, and a second business interaction thread running on a second operating system, wherein the first business interaction thread is used to acquire business data generated by the first operating system during processor operation; store the business data in the storage space on the processor; send an eighth interrupt request to the second business interaction thread, wherein the eighth interrupt request is used to request the second operating system to read the business data from the storage space; and the second operating system is used to respond to the eighth interrupt request to read the business data from the storage space.

[0542] Optionally, in this embodiment, the process of business data interaction between operating systems is similar to that in the previous embodiments, and will not be described in detail here.

[0543] In one optional implementation, a process for implementing inter-operating system business data communication based on hardware modules is provided, taking an RTOS as the first operating system and Linux as the second operating system as an example. Figure 13 This is a schematic diagram of an inter-operating system business data communication process according to an optional implementation of this application, such as... Figure 13 As shown, Linux and RTOS have the capability for business interaction. This capability can be achieved, but is not limited to, inter-core communication. For example, it can be implemented using a shared memory-based communication architecture, employing a mailbox as a hardware module. The mailbox's role is to transfer memory pointers from the Linux kernel to the RTOS kernel, with pointer sending and receiving using independent mailbox channels. Shared memory can be accessed by all cores, and this shared memory space can originate from a fixed storage area of ​​system memory (DDR). The Linux kernel first writes data to the shared memory, then the mailbox forwards interrupt requests to the RTOS kernel. Upon receiving the interrupt request, the RTOS kernel can directly read data from the shared memory. Because this process does not involve data copying, communication efficiency is high, making it particularly suitable for large data volume transfers.

[0544] The inter-system business interaction thread running on Linux (i.e., the second business interaction thread mentioned above) is simply referred to as the Linux thread, and the inter-system business interaction thread running on the RTOS (i.e., the first business interaction thread mentioned above) is simply referred to as the RTOS thread. The above-mentioned heterogeneous multi-system core inter-communication process may include, but is not limited to, the following steps: Step 1: The Linux thread copies data to a specified location 1 in the shared memory.

[0545] Step 2: The Linux thread writes the address 1 of the specified location 1 in the shared memory and the interrupt request information to channel A of the hardware module mailbox.

[0546] Step 3: The RTOS thread receives the interrupt request and address 1 from channel A of the hardware module mailbox.

[0547] Step 4: The RTOS thread reads the data stored at address 1 from the shared memory.

[0548] Step 5: The RTOS thread copies the data to the specified location 2 in the shared memory.

[0549] Step 6: The RTOS thread writes the address 2 of the specified location 2 in the shared memory and the interrupt request information to channel B of the hardware module Mailbox.

[0550] Step 7: The Linux thread receives the interrupt request and address 2 from channel B of the hardware module mailbox.

[0551] Step 8: The Linux thread reads data from address 2 in the shared memory.

[0552] The above-mentioned inter-core communication mechanism enables message passing, processing, and response between Linux inter-system business interaction threads and RTOS inter-system business interaction threads.

[0553] In one exemplary embodiment, the controller is further configured to: control the first operating system to run periodically based on the processor; or, in response to a received wake-up request, control the first operating system to run based on the processor; or, control the first operating system to run based on the processor based on the matching degree between the operation services generated on the processor and the first operating system.

[0554] Optionally, in this embodiment, the controller's wake-up control process for the first operating system is similar to that in the previous embodiments, and will not be described in detail here.

[0555] In one exemplary embodiment, the controller is configured to: detect service information of a current operation service generated on the processor; and, if the matching degree between the service information and the first operating system is detected to be higher than a matching degree threshold, control the first operating system to run the current operation service based on the processor.

[0556] Optionally, in this embodiment, the process by which the controller determines the compatibility between the operating services and the first operating system is similar to that in the previous embodiments, and will not be repeated here.

[0557] In an exemplary embodiment, the controller is configured to: detect the target response speed and / or the target resource usage of a current operating service, wherein the service information includes: the target response speed and / or the resource usage, the target response speed being the response speed that the processor needs to achieve for the current operating service, and the target resource usage being the amount of resources that the processor needs to provide for the current operating service; and, if the target response speed is less than or equal to a speed threshold, and / or the target resource usage is less than or equal to a usage threshold, determine that the matching degree between the service information and the first operating system is higher than the matching degree threshold.

[0558] Optionally, in this embodiment, the controller's processing of business information is similar to that in the previous embodiments, and will not be described in detail here.

[0559] In one exemplary embodiment, the controller is further configured to: control the first operating system to hibernate after it has finished running.

[0560] Optionally, in this embodiment, the controller's hibernation control process for the first operating system is similar to that in the previous embodiments, and will not be described in detail here.

[0561] In an exemplary embodiment, the embedded system further includes: a first business interaction thread running on a first operating system, and a second business interaction thread running on a second operating system, wherein the first business interaction thread is used to notify the second business interaction thread to allow the use of 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 to the scheduling resource pool of the second operating system during the hibernation period of the first operating system, and the scheduling resource pool includes other processors besides the target processor core.

[0562] Optionally, in this embodiment, the process by which the second operating system occupies the processor core during the hibernation period of the first operating system is similar to that in the previous embodiments, and will not be described in detail here.

[0563] In one exemplary embodiment, the embedded system further includes: a service takeover thread running on a first operating system, wherein the service takeover thread is used to monitor the operational services executed on a second operating system; and to take over the abnormal operational services if abnormal operational services are detected among the operational services executed on the second operating system.

[0564] Optionally, in this embodiment, a service takeover thread is deployed on the first operating system to monitor the operational services executed on the second operating system.

[0565] Optionally, in this embodiment, the monitoring process of the operational services executed on the second operating system is similar to that in the previous embodiments, and will not be described in detail here.

[0566] In one exemplary embodiment, the service takeover thread is configured to: receive a heartbeat signal for each operational service executed on the second operating system; and determine operational services whose heartbeat signal frequency does not conform to the corresponding target frequency as abnormal operational services.

[0567] Optionally, in this embodiment, the process by which the service takeover thread monitors abnormal operation services through the frequency of heartbeat signals is similar to that in the previous embodiments, and will not be described in detail here.

[0568] In one exemplary embodiment, the service takeover thread is further configured to: after taking over the abnormal operation service through the first operat...

Claims

1. An embedded system, characterized by include: The chip and at least two operating systems, among which, The chip includes a processor, a hardware controller, a first bus, and a second bus, wherein the bandwidth of the first bus is higher than that of the second bus, and the first bus is configured in a multi-master multi-slave mode, while the second bus is configured in a single-master multi-slave mode. The at least two operating systems run on the processor; The at least two operating systems communicate via the first bus; The at least two operating systems control the hardware controller via the second bus; The at least two operating systems include a first operating system and a second operating system, wherein, The first operating system controls the target hardware controller to run target operation services based on the processor; When the target operation service reaches the 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 run the target operation service through the second bus.

2. The embedded system according to claim 1, characterized in that, The second operating system sends a first interrupt request to the first operating system via the first bus, wherein the first interrupt request is used to request takeover of the target hardware controller; the first operating system responds to the first interrupt request by releasing the target hardware controller via the second bus; or... When the service attributes of the target operation service reach the target service attributes, the first operating system releases the target hardware controller through the second bus.

3. The embedded system according to claim 2, characterized in that, The first operating system responds to the first interrupt request to determine whether the second operating system should take over the target hardware controller; When the first operating system is taken over by the second operating system, the target hardware controller is released via the second bus.

4. The embedded system according to claim 3, characterized in that, The first operating system sends a second interrupt request to the second operating system via the first bus without the second operating system taking over the target hardware controller. The second interrupt request is used to indicate that the second operating system is refused to take over the target hardware controller.

5. The embedded system according to claim 1, characterized in that, The first operating system sends a third interrupt request to the second operating system, wherein the third interrupt request is used to indicate that the first operating system has released the target hardware controller; The second operating system responds to the third interrupt request by controlling the target hardware controller to run the target operation service via the second bus.

6. The embedded system according to any one of claims 1 to 5, characterized in that, The first operating system runs based on the target processor core in the processor; The first operating system releases the target processor core when it reaches the target system state; The second operating system adds the target processor core to the scheduling resource pool of the second operating system, wherein the scheduling resource pool includes the processor cores allocated to the second operating system in the processor.

7. The embedded system according to claim 6, characterized in that, The second operating system sends a fourth interrupt request to the first operating system via the first bus, wherein the fourth interrupt request is used to request the use of the target processor core; the first operating system responds to the fourth interrupt request to release the target processor core; or... The first operating system releases the target processor core when the system attributes reach the target system attributes.

8. The embedded system according to claim 7, characterized in that, The first operating system responds to the fourth interrupt request to determine whether the second operating system occupies the target processor core; The first operating system releases the target processor core when it is occupied by the second operating system.

9. The embedded system according to claim 8, characterized in that, The first operating system sends a fifth interrupt request to the second operating system via the first bus without the second operating system occupying the target processor core. The fifth interrupt request is used to indicate that the second operating system is not allowed to occupy the target processor core.

10. The embedded system according to claim 6, characterized in that, The first operating system sends a sixth interrupt request to the second operating system, wherein the sixth interrupt request is used to indicate that the first operating system has released the target processor core; The second operating system responds to the sixth interrupt request by adding the target processor core to the scheduling resource pool.

11. The embedded system according to claim 1, characterized in that, The target processor core in the processor has been added to the scheduling resource pool of the second operating system, wherein the scheduling resource pool includes the processor core in the processor allocated to the second operating system; The second operating system releases the target processor core when the first operating system is woken up; The first operating system runs on the target processor core.

12. The embedded system according to claim 11, characterized in that, The second operating system releases the target processor core when it detects that the first operating system has been woken up; or, When the first operating system is woken up, it sends a seventh interrupt request to the second operating system, wherein the seventh interrupt request is used to request the second operating system to release the target processor core; the second operating system responds to the seventh interrupt request and releases the target processor core.

13. The embedded system of claim 1, wherein, The chip also includes storage space, which is controlled by the at least two operating systems via the first bus. The first operating system generates business data during the operation of the processor; The first operating system stores the service data in the storage space via the first bus, and sends an eighth interrupt request to the second operating system via the first bus, wherein 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 responds to the eighth interrupt request by reading the business data from the storage space.

14. The embedded system according to claim 1, characterized in that, The first operating system runs periodically based on the processor; or, The first operating system responds to the received wake-up request by running based on the processor; or, The first operating system runs based on the processor according to the matching degree between the current operation service generated on the processor and the first operating system.

15. The embedded system according to claim 14, characterized in that, The first operating system hibernates after it finishes running; During the hibernation period of the first operating system, the second operating system adds the target processor core used by the first operating system to the scheduling resource pool of the second operating system, wherein the scheduling resource pool includes other processors besides the target processor core.

16. The embedded system according to claim 1, characterized in that, The at least two operating systems communicate via a communication protocol deployed on the first bus; or... The at least two operating systems communicate with the communication hardware controller in the hardware controller via the first bus, the second bus, and the communication hardware controller in the hardware controller.

17. The embedded system according to claim 16, characterized in that, The at least two operating systems communicate by sending inter-processor interrupt requests through the first bus; or... One of the at least two operating systems sends a system interrupt request to the first bus; the first bus forwards the system interrupt request to the second bus; the second bus sends the system interrupt request to the mailbox hardware module controlled by the communication hardware controller. The mailbox hardware module sends the system interrupt request to another operating system among the at least two operating systems via the second bus and the first bus.

18. The embedded system according to claim 1, characterized in that, The first operating system monitors the operational services executed on the second operating system through the first bus; When an abnormal operation occurs in the operation service executed by the first operating system on the second operating system, the abnormal operation service is taken over through the first bus.

19. The embedded system according to claim 18, characterized in that, The first operating system receives heartbeat signals from the operational services executed on the second operating system via the first bus; The first operating system takes over operations that do not conform to the target frequency of the heartbeat signal as abnormal operations through the first bus.

20. The embedded system according to claim 18, characterized in that, After taking over the abnormal operation service, the first operating system sends a restart command to the second operating system through the first bus, wherein the restart command is used to instruct the abnormal operation service to be restarted.

21. The embedded system according to claim 1, characterized in that, The chip also includes a memory, which stores a boot module. After the chip is powered on, the boot module runs to boot one of the at least two operating systems, and the boot module boots the other operating systems.

22. The embedded system according to claim 1, characterized in that, The first operating system runs based on the target processor core in the processor; the first operating system releases the target processor core when it reaches the target system state; The second operating system adds the target processor core to the scheduling resource pool of the second operating system, wherein the scheduling resource pool includes the processor cores allocated to the second operating system in the processor; The chip also includes a storage space, and the at least two operating systems control the storage space through the first bus. The first operating system generates business data based on the processor's operation. The first operating system stores the business data in the storage space through the first bus and sends an eighth interrupt request to the second operating system through the first bus. The eighth interrupt request is used to request the second operating system to read the business data from the storage space. The second operating system responds to the eighth interrupt request and reads the business data from the storage space.

23. The embedded system according to claim 1, characterized in that, The chip loads communication values ​​onto the first bus, and the first bus sends communication signals carrying the communication values ​​to the communication register corresponding to the second operating system to realize communication between the first operating system and the second operating system. The communication values ​​are used to indicate the communication content between the first operating system and the second operating system.

24. The embedded system according to claim 1, characterized in that, The chip loads control values ​​onto the second bus, and the second bus sends control signals carrying the control values ​​to the registers corresponding to the hardware controller, so as to enable the operating system to control the hardware controller. The control values ​​are used to indicate the control content of the operating system on the hardware controller.

25. An embedded system, characterized in that, include: A first operating system, a second operating system, a controller, and a processor, wherein the first operating system and the second operating system run on the processor. The controller is used to detect the running status of the first operating system during operation, and control the processor resources used by the first operating system according to the running status; The controller is used to detect the system state of the first operating system, wherein the running state includes the system state, and the first operating system runs based on the target processor core in the processor; The controller is configured to release the target processor core when the system state is detected to be the target system state, wherein the processor resources include the target processor core; the second operating system is configured to add the target processor core to the scheduling resource pool of the second operating system, wherein the scheduling resource pool includes the processor cores allocated to the second operating system in the processor. The embedded system further includes: a first business interaction thread running on the first operating system, and a second business interaction thread running on the second operating system. The first business interaction thread is used to send a sixth interrupt request to the second business interaction thread, wherein the sixth interrupt request is used to indicate that the first operating system has released the target processor core; The second operating system is used to add the target processor core to the scheduling resource pool in response to the sixth interrupt request.

26. The embedded system according to claim 25, characterized in that, The controller is used for: The service status of the target operation service run by the first operating system based on the processor is detected, wherein the operation status includes the service status.

27. The embedded system according to claim 26, characterized in that, The controller is configured to release the target operation service when the service state is detected to be the target operation service state, wherein the processor resources include the target operation service; the second operating system is configured to run the target operation service.

28. The embedded system according to claim 27, characterized in that, The controller is configured to, upon receiving a first interrupt request sent by the second service interaction thread to the first service interaction thread, determine that the detected service state is the target service state, wherein the first interrupt request is used to request takeover of the target operation service; or... The controller is configured to determine that the detected service state is the target service state when the service attributes of the target operation service reach the target service attributes.

29. The embedded system according to claim 28, characterized in that, The controller is used for: In response to the first interrupt request, determine whether the second operating system should take over the target operation service; If the target operation service is taken over by the second operating system, the target operation service is released.

30. The embedded system according to claim 29, characterized in that, The first business interaction thread is used to send a second interruption request to the second business interaction thread when the target operation business is not taken over by the second operating system, wherein the second interruption request is used to indicate that the second operating system is refused to take over the target operation business.

31. The embedded system according to claim 27, characterized in that, The first business interaction thread is used to send a third interrupt request to the second business interaction thread, wherein the third interrupt request is used to indicate that the target hardware controller has been released; The second operating system is used to control the target hardware controller to run the target operation service in response to the third interrupt request.

32. The embedded system according to claim 25, characterized in that, The controller is configured to, upon receiving a fourth interrupt request sent by the second service interaction thread to the first service interaction thread, determine that the detected system state is the target system state, wherein the fourth interrupt request is used to request the use of the target processor core; or, The controller is configured to determine that the detected system state is the target system state when the system attributes of the first operating system reach the target system attributes.

33. The embedded system according to claim 32, characterized in that, The controller is used for: In response to the fourth interrupt request, determine whether the target processor core is occupied by the second operating system; If the target processor core is occupied by the second operating system, release the target processor core.

34. The embedded system according to claim 33, characterized in that, The first service interaction thread is used to send a fifth interrupt request to the second service interaction thread when the target processor core is not occupied by the second operating system, wherein the fifth interrupt request is used to indicate that the second operating system is refused to occupy the target processor core.

35. The embedded system according to claim 25, characterized in that, The controller is also used for: When the target processor core in the processor has been added to the scheduling resource pool of the second operating system, and the first operating system is woken up and running, it is detected whether the target processor core has been released, wherein the scheduling resource pool includes the processor core in the processor allocated to the second operating system; If it is detected that the second operating system has released the target processor core when the first operating system is woken up, the first operating system is run based on the target processor core.

36. The embedded system according to claim 35, characterized in that, The first service interaction thread is used to send a seventh interrupt request to the second service interaction thread when it is detected that the target processor core has not been released, wherein the seventh interrupt request is used to request the second operating system to release the target processor core; The second operating system is used to release the target processor core in response to the seventh interrupt request.

37. The embedded system according to any one of claims 25 to 36, characterized in that, The first business interaction thread is used to acquire business data generated during the operation of the first operating system based on the processor; and to store the business data in the storage space on the processor. Send an eighth interrupt request to the second business interaction thread, wherein the eighth interrupt request is used to request the second operating system to read the business data from the storage space; The second operating system is used to read the business data from the storage space in response to the eighth interrupt request.

38. The embedded system according to claim 25, characterized in that, The controller is also used for: Control the first operating system to run periodically based on the processor; or, In response to a received wake-up request, control the first operating system to run based on the processor; or, Based on the compatibility between the operational services generated on the processor and the first operating system, the first operating system is controlled to run on the processor.

39. The embedded system according to claim 38, characterized in that, The controller is used for: Detect the service information of the current operation service generated on the processor; If the matching degree between the service information and the first operating system is detected to be higher than the matching degree threshold, the first operating system is controlled to run the current operation service based on the processor.

40. The embedded system according to claim 39, characterized in that, The controller is used for: The target response speed and / or target resource consumption of the current operation service are detected, wherein the service information includes: target response speed and / or resource consumption, the target response speed is the response speed that the processor needs to achieve for the current operation service, and the target resource consumption is the amount of resources that the processor needs to provide for the current operation service; If the target response speed is less than or equal to a speed threshold, and / or the target resource usage is less than or equal to a usage threshold, then the matching degree between the service information and the first operating system is determined to be higher than the matching degree threshold.

41. The embedded system according to claim 38, characterized in that, The controller is also used for: Control the first operating system to hibernate after it finishes running.

42. The embedded system according to claim 41, characterized in that, The first business interaction thread is used to notify the second business interaction thread that it is allowed to use 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 to the scheduling resource pool of the second operating system during the hibernation period of the first operating system. The scheduling resource pool includes other processors besides the target processor core.

43. The embedded system according to claim 25, characterized in that, The embedded system further includes: a service takeover thread running on the first operating system, wherein... The service takeover thread is used to monitor the operational services executed on the second operating system; if abnormal operational services are detected among the operational services executed on the second operating system, the thread takes over the abnormal operational services.

44. The embedded system according to claim 43, characterized in that, The business takeover thread is used for: Receive the heartbeat signal for each operation performed on the second operating system; Operations whose heartbeat signal frequency does not match the corresponding target frequency are identified as abnormal operations.

45. The embedded system according to claim 43, characterized in that, The business takeover thread is also used for: After taking over the abnormal operation service through the first operating system, a restart command is sent to the second operating system, wherein the restart command is used to instruct the abnormal operation service to be restarted.

46. ​​The embedded system according to claim 25, characterized in that, The embedded system also includes a boot module. The boot module is used to boot the first operating system and boot the second operating system.

47. A method for controlling the operation of an operating system, characterized in that, include: The running status of the first operating system during operation is detected, wherein the first operating system and the second operating system run based on the processor; Control the processor resources used by the first operating system according to the running status; The step of detecting the running status of the first operating system during operation includes: detecting the system status of the first operating system, wherein the running status includes the system status, and the first operating system runs based on the target processor core in the processor; The step of controlling the processor resources used by the first operating system according to the running state includes: releasing the target processor core when the system state is detected to be the target system state, wherein the processor resources include the target processor core, and the second operating system is used to add the target processor core to the scheduling resource pool of the second operating system, wherein the scheduling resource pool includes the processor cores allocated to the second operating system in the processor. The method further includes: sending a sixth interrupt request to a second business interaction thread, wherein the sixth interrupt request is used to indicate that the first operating system has released the target processor core, and the second operating system is used to respond to the sixth interrupt request by adding the target processor core to the scheduling resource pool.

48. The method according to claim 47, characterized in that, The detection of the running status of the first operating system during operation includes: The service status of the target operation service run by the first operating system based on the processor is detected, wherein the operation status includes the service status.

49. The method according to claim 48, characterized in that, The step of controlling the processor resources used by the first operating system according to the operating state includes: If the service status is detected to be the target service status, the target operation service is released, wherein the processor resources include the target operation service, and the second operating system is used to run the target operation service.

50. The method according to claim 49, characterized in that, The method further includes: Upon receiving a first interrupt request sent by the second operating system to the first operating system, it is determined that the detected service state is the target service state, wherein the first interrupt request is used to request takeover of the target operation service; or... If the business attributes of the target operation service meet the target business attributes, the detected business state is determined to be the target business state.

51. The method according to claim 50, characterized in that, The step of releasing the target operation service when the service status is detected to be the target service status includes: In response to the first interrupt request, determine whether the second operating system should take over the target operation service; If the target hardware controller is taken over by the second operating system, the target operating services are released.

52. The method according to claim 47, characterized in that, The method further includes: Upon receiving a fourth interrupt request sent by the second operating system to the first operating system, it is determined that the detected system state is the target system state, wherein the fourth interrupt request is used to request the use of the target processor core; or, If the system attributes of the first operating system reach the target system attributes, the system state is determined to be the target system state.

53. The method according to claim 52, characterized in that, The step of releasing the target processor core when the system state is detected to be the target system state includes: In response to the fourth interrupt request, determine whether the target processor core is occupied by the second operating system; If the target processor core is occupied by the second operating system, release the target processor core.

54. The method according to any one of claims 47 to 53, characterized in that, The method further includes: Acquire business data generated during the operation of the first operating system based on the processor; The business data is stored in the storage space on the processor; An eighth interrupt request is sent 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 respond to the eighth interrupt request to read the service data from the storage space.

55. The method according to claim 47, characterized in that, The method further includes: Control the first operating system to run periodically based on the processor; or, In response to a received wake-up request, control the first operating system to run based on the processor; or, Based on the compatibility between the operational services generated on the processor and the first operating system, the first operating system is controlled to run on the processor.

56. The method according to claim 55, characterized in that, The step of controlling the first operating system to run based on the processor according to the matching degree between the current operation service generated on the processor and the first operating system includes: Detect the service information of the current operation service generated on the processor; If the matching degree between the service information and the first operating system is detected to be higher than the matching degree threshold, the first operating system is controlled to run the current operation service based on the processor.

57. The method according to claim 47, characterized in that, The method further includes: Monitor the operational processes executed on the second operating system; If abnormal operation is detected in the operation services executed on the second operating system, the abnormal operation service is taken over by the first operating system.

58. An operating system operation control device, characterized in that, include: The first detection module is used to detect the running status of the first operating system during operation, wherein the first operating system and the second operating system run based on the processor; The control module is used to control the processor resources used by the first operating system according to the operating status; The first detection module is used to detect the system status of the first operating system, wherein the running status includes the system status, and the first operating system runs based on the target processor core in the processor; The control module is configured to: release the target processor core when the system state is detected to be the target system state, wherein the processor resources include the target processor core, and the second operating system is configured to add the target processor core to the scheduling resource pool of the second operating system, wherein the scheduling resource pool includes the processor cores allocated to the second operating system in the processor. The device is further configured to: send a sixth interrupt request to a second business interaction thread, wherein the sixth interrupt request is used to indicate that the first operating system has released the target processor core, and the second operating system is used to respond to the sixth interrupt request by adding the target processor core to the scheduling resource pool.

59. A chip, characterized in that, The chip includes at least one of programmable logic circuitry and executable instructions, and the chip operates in an electronic device to implement the method of any one of claims 47 to 57.

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

61. A motherboard, characterized in that, include: At least one processor; At least one memory for storing at least one program; When the at least one program is executed by the at least one processor, the at least one processor performs the method as described in any one of claims 47 to 57.

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

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

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

Images