Embedded system startup control method and device, storage medium, and electronic device

Abstract

The present invention discloses a startup control method and apparatus for an embedded system, a storage medium, and an electronic device. Here, the method is to control the operating state of a target device by controlling a hardware controller of the target device via a first bus by a first operating system running on a first processor core of a processor, where the embedded system includes the first operating system, and to guide a second operating system to be started on a second processor core of the processor, where the embedded system further includes the second operating system, the response speed of the first operating system is higher than that of the second operating system, the first operating system and the second operating system communicate via a second bus, and the bandwidth of the second bus is higher than that of the first bus, and after the second operating system is started, the second operating system takes over the control of the target device by taking over the hardware controller via the first bus.

Description

[Technical Field]

[0001] The present invention relates to the computer field, and more particularly to a startup control method and device for an embedded system, a storage medium and an electronic device. [Background technology]

[0002] A device such as a server, a personal computer, or an industrial control computer may be equipped with several specific devices that perform operations related to the operation of the device, such as a fan for heat dissipation. In the related art, these specific devices generally start operating after the system is powered on. After the system is powered on, it takes a certain amount of time for the operating system running on the processor to properly take over and control the operation status of the specific devices. Therefore, the operating system cannot control the specific devices during startup.

[0003] In order to control the running state of a specific device during the startup process of an operating system, an additional chip is generally used to control the running state of a specific device during the startup process of an operating system, but the above-mentioned operating system startup control method requires the addition of an additional chip, which increases the cost of the device. Therefore, the operating system startup control method of the related art has a problem in that the cost of the device is high because it requires the addition of an additional chip. Summary of the Invention [Problem to be solved by the invention]

[0004] The embodiments of the present invention provide a startup control method and device for an embedded system, a storage medium, and an electronic device that at least solve the problem that the startup control method of an operating system in the related art requires the addition of an additional chip, resulting in high equipment costs. [Means for solving the problem]

[0005] According to one aspect of an embodiment of the present invention, there is provided a startup control method for an embedded system, comprising: controlling an operating state of a target device by a first operating system running on a first processor core of a processor, by controlling a hardware controller of the target device via a first bus, wherein the embedded system includes the first operating system; and guiding a second operating system to start on a second processor core of the processor, wherein the embedded system further includes the second operating system, the first operating system having a higher response speed than the second operating system, the first operating system and the second operating system communicating via a second bus, the bandwidth of the second bus being higher than the bandwidth of the first bus; and after the second operating system is started, having the second operating system take over the hardware controller via the first bus, thereby taking over control of the target device.

[0006] According to another aspect of the embodiment of the present invention, there is further provided a startup control device for an embedded system, comprising: a first control unit for controlling an operating state of a target device by controlling a hardware controller of the target device via a first bus by a first operating system running on a first processor core of a processor, wherein the embedded system includes the first control unit including the first operating system; a startup unit for guiding a second operating system to start on a second processor core of the processor, wherein the embedded system further includes the second operating system, the response speed of the first operating system being higher than that of the second operating system, the first operating system and the second operating system communicating via a second bus, and a bandwidth of the second bus being higher than that of the first bus; and a first execution unit for having the second operating system take over control of the target device by taking over the hardware controller via the first bus after the second operating system is started.

[0007] In one exemplary embodiment, the first control unit includes a first execution module for executing a first control task of the first operating system on the first processor core, wherein the first control task includes: a first execution module used to control the hardware controller; a reading module for reading sensor data of a predetermined sensor corresponding to the target device by the first processor core; and a first transmission module for transmitting an equipment control command to the hardware controller via the first bus based on the sensor data of the predetermined sensor by the first control task, thereby controlling the operating state of the target device by the hardware controller based on the equipment control command.

[0008] In one exemplary embodiment, the first transmission module includes a first determination submodule for determining, by the first control task, a target parameter value of an equipment operating parameter of the target equipment based on sensor data of the specified sensor, where the equipment operating parameter is a parameter that controls the operating state of the target equipment, and a transmission submodule for transmitting, by the first control task, the equipment control command including the target parameter value to the hardware controller via the first bus.

[0009] In one exemplary embodiment, the first determination submodule includes a determination subunit for determining, when the target equipment is a fan, a target parameter value of a fan operation parameter of the fan based on sensor data of the specified sensor by the first control task. In one exemplary embodiment, the determination subunit includes a determination second subunit for determining, by the first control task, a target rotational speed value of the fan based on sensor data of the temperature sensor when the target device is a fan and the specified sensor is a temperature sensor, wherein the fan rotational speed has a positive correlation with the temperature detected by the temperature sensor.

[0010] In one exemplary embodiment, the first execution unit includes: a second transmitting module for transmitting a first inter-core interrupt to the first operating system via the second bus by the second operating system, where the first inter-core interrupt is used to request that the second operating system take over the hardware controller; and a control module for controlling the hardware controller via the first bus by a second control task of the second operating system when the first operating system receives a second inter-core interrupt in response to the first inter-core interrupt, indicating agreement to have the second operating system take over the hardware controller, where the second control task is used to control the hardware controller.

[0011] In one exemplary embodiment, the apparatus further includes: a second control unit for controlling a third control task of the first operating system to sleep in response to the acquired first inter-core interrupt after the second operating system sends a first inter-core interrupt to the first operating system via the second bus as described above, wherein the third control task is used to control the hardware controller; and a first sending unit for sending the second inter-core interrupt to the second operating system via the second bus by the first operating system if the third control task has already gone to sleep.

[0012] In one exemplary embodiment, the apparatus further includes a second execution unit for pushing system operation data of the first operating system onto a stack if the third control task has already gone to sleep, wherein the second inter-core interrupt is further used to instruct the second operating system to take over the first processor core.

[0013] In one exemplary embodiment, the apparatus further includes a wake-up unit for waking up the first processor core by the processor after a chip on which the processor is located is powered on before controlling a hardware controller of a target device via a first bus by a first operating system running on a first processor core of the processor, and an operation unit for guiding the first operating system to start on the first processor core by running a boot loader program of the first operating system by the first processor core.

[0014] In one exemplary embodiment, the startup unit includes a second execution module for waking up the second processor core through a second program loader by executing the second program loader by the first processor core, and a running module for guiding the second operating system to start on the first processor core by running a generic boot loader of the second operating system by the second processor core.

[0015] In one exemplary embodiment, the device further includes a third execution unit for taking over control of the target device by having the second operating system wake up the first operating system via the second bus and having the first operating system take over the hardware controller via the first bus when the second operating system is to be restarted after the second operating system takes over the hardware controller via the first bus as described above, and a third control unit for controlling the second operating system to restart the system.

[0016] In one exemplary embodiment, the third execution unit includes a transmitting module for transmitting, by the second operating system, a system wake-up interrupt to the first operating system via the second bus to wake up the first operating system when the second operating system is to be restarted.

[0017] In one exemplary embodiment, the apparatus further includes: a first allocation unit for allocating a group of allocation target services to corresponding operating systems among the first operating system and the second operating system according to a resource dynamic allocation rule, where the resource dynamic allocation rule includes performing resource dynamic allocation based on at least one of a service response speed, a service resource occupancy rate, a service coupling degree, and a service importance; a first determination unit for determining a resource allocation result corresponding to the group of allocation target services, where the resource allocation result is used to indicate a processing resource of the processor corresponding to each allocation target service among the group of allocation target services, where the processing resource of the processor includes a processor core; and a second allocation unit for allocating the processing resources of the processor to the first operating system and the second operating system based on the operating systems corresponding to each allocation target service and the resource allocation result.

[0018] In one exemplary embodiment, the first allocation unit includes: a first allocation module for allocating, to the first operating system, those services among the group whose service response speed requirements are equal to or greater than a set response speed threshold, and for allocating, to the second operating system, those services among the group whose service response speed requirements are smaller than a set response speed threshold; a second allocation module for allocating, to the first operating system, those services among the group whose service resource occupancy rates are smaller than a first occupancy threshold, and for allocating, to the second operating system, those services among the group whose service resource occupancy rates are equal to or greater than the first occupancy threshold; and a third allocation module for allocating, to a target operating system, those services among the group whose sensitive information is included, wherein the target operating system is at least one of the first operating system and the second operating system, which is an operating system that interacts less frequently with a user.

[0019] In one exemplary embodiment, the first allocation unit includes at least one of a fourth allocation module for allocating to the first operating system a service to be allocated among the services to be allocated in the one group, the service coupling degree with an already allocated service of the first operating system being equal to or greater than a first coupling threshold, and a fifth allocation module for allocating to the second operating system a service to be allocated among the services to be allocated in the one group, the service coupling degree with an already allocated service of the second operating system being equal to or greater than a second coupling threshold.

[0020] In one exemplary embodiment, the first determination unit includes a generation module for generating a resource mapping table of the services to be allocated in the one group and the processing resources of the processor by linking the resource utilization status of the processing resources of the first operating system and the resource utilization status of the processing resources of the second operating system based on the allocation results of the services to be allocated in the one group.

[0021] In one exemplary embodiment, the second allocation unit includes a sixth allocation module for, when determining based on the resource allocation result that an unallocated processing resource among the processing resources of the processor has a corresponding service to be allocated, allocating the unallocated processing resource to an operating system to which the service to be allocated corresponding to the unallocated processing resource is assigned.

[0022] In one exemplary embodiment, the apparatus further includes: a second sending unit for sending target data to a target virtual channel in the memory of the processor by the first operating system; a third sending unit for sending an interrupt notification message to the second operating system; and an acquiring unit for the second operating system to acquire the target data from the target virtual channel in the memory by responding to the interrupt notification message.

[0023] In one exemplary embodiment, the memory includes a data storage area and a metadata storage area, the data storage area is partitioned into a plurality of storage units, each storage unit is used to store service data, and the metadata storage area is used to store the size and occupancy status of each storage unit in the data storage area. In one exemplary embodiment, the second sending unit includes a third execution module for reading, by the first operating system, a record in the metadata storage area, and based on the read record, determining at least one storage unit in the data storage area that is in an idle state and whose total space is equal to or greater than the length of the target data, to obtain the target virtual channel; and a fourth execution module for 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.

[0024] In one exemplary embodiment, the acquisition unit includes a fifth execution module for reading records in the metadata storage area and determining the target virtual channel based on the read records by the second operating system, and a sixth execution module for acquiring the target data from at least one storage unit corresponding to the target virtual channel and setting a state of the at least one storage unit to an idle state.

[0025] In one exemplary embodiment, the data storage area includes a plurality of memory channels, each memory channel being composed of one or more storage units; a plurality of records are stored in the metadata storage area, each record being used to record metadata of one memory channel, the metadata of each memory channel including at least a channel ID of the memory channel, a size of the memory channel, and an occupied status of the memory channel; and the third execution module includes: a first traversal submodule for traversing the records stored in the metadata storage area to determine whether there is a first target record indicating that the memory channel is in an idle state and that the size of the memory channel is greater than or equal to the length of the target data; and a second determination submodule for determining, if the first target record exists, a memory channel indicated by a channel ID recorded in the first target record as the target virtual channel.

[0026] In one exemplary embodiment, when a memory channel is occupied, the metadata of the memory channel further includes an ID of an originating CPU core of the target data and an ID of a destination CPU core of the target data, and the fifth execution module includes: a second traversal submodule for traversing records stored in the metadata storage area to determine whether a second target record exists, where the second target record indicates that the memory channel is in an occupied state and the ID of the destination CPU core is the ID of a CPU core of the second operating system and the ID of the originating CPU core is not the ID of a CPU core of the second operating system; and a third determination submodule for determining, when the second target record exists, a memory channel indicated by a channel ID recorded in the second target record as the target virtual channel.

[0027] In one exemplary embodiment, the device further includes: a fourth execution unit for receiving a memory application command of the first operating system and performing a lock operation on the memory of the processor, where the memory application command is used to apply for use of the memory of the processor; a fifth execution unit for reading an occupied state of the memory if the lock on the memory is successful, and determining whether there is a free target memory space in the memory based on the occupied state of the memory, where the size of the target memory space is equal to or greater than the size of the memory applied for by the memory application command; and a feedback unit for feeding back address information of the target memory space to the first operating system and updating the occupied state of the memory if the target memory space exists in the memory.

[0028] In one exemplary embodiment, the memory includes a metadata storage area in which a state mapping table for storing the occupied state of a data storage area is stored, and a data storage area for storing service data, and the fifth execution unit includes a seventh execution module for reading a record in the state mapping table from the metadata storage area and determining, based on the record in the state mapping table, whether the target memory space exists in the data storage area.

[0029] In one exemplary embodiment, the apparatus further includes: a judgment unit for determining whether the memory of a processor is currently in a locked state before executing a lock operation on the memory, where the locked state represents that the memory is in a state offered for use; and a sixth execution unit for executing a lock operation on the memory if the memory is not currently in a locked state.

[0030] In one exemplary embodiment, the device further includes a release unit for reading an occupied state of the memory and determining whether a free target memory space exists in the memory based on the occupied state of the memory, and then releasing a lock on the memory if the free target memory space does not exist in the memory.

[0031] According to another aspect of the present invention, an embedded system further includes 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 a bandwidth of the second bus is higher than a bandwidth of the first bus, and the second bus is configured in a multi-master multi-slave mode, and the first bus is configured in a one-master multi-slave mode, and the at least two operating systems run based on the processor, wherein processing resources of the processor are dynamically allocated to the at least two operating systems, and the processing resources of the processor include a processor core, and the at least two operating systems communicate via the second bus, and the at least two operating systems realize control over the hardware controller via the first bus, and the at least two operating systems are used to realize steps of any one of the above method embodiments.

[0032] According to another aspect of the embodiments of the present application, there is further provided a chip including at least one of a programmable logic circuit and an executable command, the chip being run in an electronic device to implement the steps in any one of the above method embodiments.

[0033] According to another aspect of an embodiment of the present application, there is further provided a BMC chip including: a memory unit for storing a program; and a processing unit connected to the memory unit for running the program so as to perform the steps in any one of the above method embodiments. According to another aspect of an embodiment of the present application, there is further provided a main board including at least one processor and at least one memory unit 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 is caused to realize the steps in any one of the above method embodiments.

[0034] According to another aspect of an embodiment of the present application, there is further provided a server including a processor, a communication interface, a memory unit, and a communication bus, wherein the processor, the communication interface, and the memory unit realize communication between each other via the communication bus, the memory unit is used to store a computer program, and the processor, when executing the program stored in the memory unit, is used to realize the steps in any one of the above method embodiments.

[0035] According to another embodiment of the present application, there is further provided a computer-readable storage medium having stored thereon a computer program which, when run, is configured to perform the steps of any one of the method embodiments described above. According to another embodiment of the present application, there is further provided an electronic device including a memory unit and a processor, wherein a computer program is stored in the memory unit, and the processor is configured to execute the steps of any one of the above method embodiments by running the computer program. [Effects of the Invention]

[0036] In an embodiment of the present invention, a method for running different operating systems of an embedded system on different processor cores of a processor includes: controlling an operating state of a target device by a first operating system running on a first processor core of the processor to control a hardware controller of the target device via a first bus, where the embedded system includes a first operating system; and guiding a second operating system to start on a second processor core of the processor, where the embedded system further includes a second operating system, where the response speed of the first operating system is higher than that of the second operating system, and the first operating system and the second operating system communicate via a second bus, where the bandwidth of the second bus is higher than that of the first bus; After the second operating system is started, the second operating system takes over the hardware controller via the first bus, thereby taking over control of the target device. At least two operating systems for the embedded system run on the processor, and different operating systems have different response speeds. The first operating system with a faster response speed first controls the running state of a specific device, and after the second operating system is started, it takes over control of the specific device. Therefore, there is no need to add an additional chip, and since the device control is realized by software, it can achieve the technical effects of being highly scalable and improving the utilization rate of core resources, thereby solving the problem in the related art that the operating system startup control method requires the addition of an additional chip, resulting in high device costs. [Brief explanation of the drawings]

[0037] The drawings herein, which are incorporated in and constitute a part of this specification, illustrate embodiments which fulfil the present application and, together with the specification, serve to explain the principles of the present application. In order to more clearly explain the technical solutions of the embodiments of the present application or the prior art, the following briefly introduces the drawings that need to be used to describe the embodiments or the prior art, and it is obvious that those skilled in the art can obtain other drawings based on these drawings without exerting any creative efforts. [Figure 1] 1 is a schematic diagram of a hardware environment of a startup control method for an embedded system according to an embodiment of the present application; [Figure 2] 1 is a flow diagram of a method for selective embedded system startup control according to an embodiment of the present application; [Figure 3] FIG. 1 is a schematic diagram of an optional fan controller according to an embodiment of the present application. [Figure 4] FIG. 1 is a schematic diagram of an alternative system energization start-up flow according to an embodiment of the present application. [Figure 5] FIG. 2 is a schematic diagram of selective inter-core interrupts according to an embodiment of the present application; [Figure 6] FIG. 10 is a flow diagram of another selective embedded system startup control method according to an embodiment of the present application. [Figure 7] 1 is a schematic diagram of a selective embedded system startup control method according to an embodiment of the present application; [Figure 8] FIG. 10 is a schematic diagram of another alternative embedded system startup control method according to an embodiment of the present application. [Figure 9] FIG. 10 is a schematic diagram of another alternative embedded system startup control method according to an embodiment of the present application. [Figure 10] 1 is a schematic diagram of an optional embedded system according to an embodiment of the present application. [Figure 11] FIG. 1 is a schematic diagram of another optional embedded system according to an embodiment of the present application. [Figure 12] FIG. 2 is a structural block diagram of a start-up control device of an optional embedded system according to an embodiment of the present application. DETAILED DESCRIPTION OF THE INVENTION

[0038] In order to help those skilled in the art better understand the technical solutions of the present application, the technical solutions in the embodiments of the present application will be described below clearly and completely in conjunction with the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only some of the embodiments of the present application, not all of the embodiments, and all other embodiments obtained by those skilled in the art based on the embodiments of the present application without any creative efforts shall all fall within the scope of protection of the present application.

[0039] It should be noted that the terms "first," "second," etc. in the specification, claims, and drawings of this application are not necessarily used to describe a particular order or chronology, but are merely used to distinguish between similar items. It should be understood that the data used in this manner can be interchanged as appropriate, and that the embodiments of the application described herein may be performed in an order other than that illustrated or described herein. Furthermore, the terms "comprise," "have," and any variations thereof are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus comprising a series of steps or units is not necessarily limited to the explicitly recited steps or units, but may include other steps or units not explicitly recited or inherent in the process, method, product, or apparatus.

[0040] An embodiment of the method according to the present application may be executed on a server, a computer terminal, a device terminal, or a similar computing device. Taking the example of running on a server, FIG. 1 is a schematic diagram of a hardware environment of the embedded system startup control method according to the present application. As shown in FIG. 1, the server may include one or more (only one is shown in FIG. 1) processors 102 (processor 102 may include, but is not limited to, a processing device such as a microprocessor MCU or a programmable logic device FPGA) and a memory unit 104 for storing data. In one exemplary embodiment, the server may further include a transmission device 106 and an input / output device 108 used for communication functions. As will be understood by those skilled in the art, the structure shown in FIG. 1 is merely exemplary and does not constitute a limitation on the structure of the server. For example, the server may include more or fewer components than those shown in FIG. 1, or may have a different configuration with functions equivalent to or greater than those shown in FIG. 1.

[0041] The memory unit 104 may be used to store computer programs, such as software programs and modules of application software, for example, a computer program corresponding to the startup control method of an embedded system according to an embodiment of the present invention. The processor 102 executes various functional applications and data processing, i.e., realizes the above-described method, by running the computer programs stored in the memory unit 104. The memory unit 104 may include a high-speed random memory unit or a non-volatile memory unit, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory units. In some embodiments, the memory unit 104 may further include a memory unit remote from the processor 102, and these remote memory units may be connected to a server via a network. Examples of such networks include, but are not limited to, the Internet, a corporate intranet, a local area network, a mobile communication network, and combinations thereof.

[0042] The transmission device 106 is used to transmit and receive data over a network. A specific example of the network may include a wireless network provided by a carrier of the server. In one embodiment, the transmission device 106 includes a network adapter (Network Interface Controller, NIC) that can connect to other network devices via a base station to communicate with the Internet. In one embodiment, the transmission device 106 may be a radio frequency (RF) module for wirelessly communicating with the Internet.

[0043] In this embodiment, a startup control method for an embedded system applied to the above-mentioned server is provided. FIG. 2 is a schematic flow diagram of a startup control method for an embedded system selected according to an embodiment of the present application. As shown in FIG. 2, the flow includes the following steps: Step S202: A first operating system running on a first processor core of the processor controls a hardware controller of the target device via a first bus to control the operating state of the target device, where the embedded system includes the first operating system.

[0044] The embedded system startup control method of this embodiment can be applied to a scenario in which an operating system runs on a processor core of a processor to control the operating state of a specific device, and can accommodate the startup process of the embedded system. The embedded system may be an embedded heterogeneous multi-system, which means that multiple different operating systems (e.g., a first operating system, a second operating system, etc.) run on the multi-core processor of the embedded system, and these operating systems run simultaneously on the same embedded system. Different operating systems can run on different processor cores, and the processor here may be a multi-core processor, for example, an 8-core processor, or a processor with other numbers of processor cores. In this embodiment, the number of cores included in the multi-core processor is not limited.

[0045] In a device such as a server, a personal computer, or an industrial control computer, some specific devices may be configured to perform operations related to the operation of the device. In the related art, generally, after the system is powered on, these specific devices start to operate. Meanwhile, after the system is powered on, it takes a certain amount of time for the operating system running on the processor to properly take over the specific devices and control the operating status of the specific devices, and the operating system cannot control the specific devices during the startup process.

[0046] For example, the fan starts operating after the system is turned on, and after the system is turned on, it takes a certain amount of time for the operating system running on the CPU (Central Processing Unit, the core of the computer system's calculation and control; the CPU is the final execution unit for information processing and program execution) to properly take over the fan and set the fan rotation speed, so the fan cannot be controlled during the operating system startup process.

[0047] In the related art, in order to realize control of the running state of a specific device during the startup process of an operating system, an additional chip is generally used to control the running state of the specific device during the startup process of the operating system. The additional chip may be a CPLD (Complex Programmable Logic Device), an EC (Embedded Controller) chip, a customized chip, etc. The main reason for using the additional chip is that the CPLD, EC chip, and customized chip can start up in a very short time (e.g., within one second) after being powered on, thereby providing relatively high real-time performance. However, these three methods generally require an additional chip or a complex programmable logic device, which increases costs, and because they require customized hardware, they do not have good scalability.

[0048] For example, to achieve fan control during the operating system startup process, servers adopt a control method that combines a CPLD with a BMC (Baseboard Management Controller, a management control chip in the server platform), personal computers adopt a control method using an EC chip (the EC chip has the function of adjusting the fan speed based on temperature), and industrial control computers adopt a control method using a customized chip. During the startup process of the operating systems of servers, personal computers, and industrial control computers, the CPLD, EC chip, and customized chip participate in controlling the fan speed, and after the operating system has fully started, control of the fan is handed over to the application program in the operating system.

[0049] In order to solve at least some of the above problems, a startup control method for a multi-core multi-system (e.g., a multi-core dual system) can be adopted, in which different operating systems of an embedded system run on different processor cores of a processor, and the response speeds of the different operating systems are different. In cases where the second operating system is not started, restarts, or cannot control the operating status of a specific device, the operating status of the specific device can be controlled by a first operating system with a higher response speed than the second operating system, thereby reducing the situation where the operating status of a specific device cannot be controlled and further providing excellent scalability since there is no need to add additional costs.

[0050] An embedded system may run on a processor, which may be a multi-core processor (e.g., an 8-core processor) or may include multiple processor cores. The embedded system may include a first operating system and a second operating system, where the first operating system may run on a first processor core of the processor and the second operating system may run on a second processor core of the processor, and the first processor core may be at least one processor core of the processor, and the second processor core may be all or some of the processor cores of the processor other than the first processor core. In addition to the processor cores, the processor resources running each operating system may further include other types of resources, such as a controller logic unit. Furthermore, the processor cores occupied by different operating systems may be dynamically adjusted.

[0051] The processor may be a processor on a chip, and the chip may include the above-mentioned processor, a hardware controller, a first bus, and a second bus, where the hardware controller may be used to control external devices connected to a corresponding external interface, the first bus may be configured in one-master multi-slave mode and may be a bus used by the processor to control between the hardware controllers, such as an APB (Advanced Peripheral Bus) bus, and the second bus may be configured in multi-master multi-slave mode and may be a bus used for communication between multiple cores of the processor 302, such as an AHB (Advanced High Performance Bus), and the bandwidth of the second bus is higher than the bandwidth of the first bus.

[0052] Here, the term "configured in multi-master multi-slave mode" means that the second bus can be used to communicate data between multiple master devices and multiple slave devices. That is, multiple master devices and multiple slave devices can be connected to the second bus, and data communication can be performed between the master devices and between the master devices and the slave devices using the second bus. Data transmission over the entire second bus is sent by the master device and responded to by the slave devices. The term "configured in one-master multi-slave mode" means that the first bus can be used to communicate data between one master device and multiple slave devices. That is, one master device and multiple slave devices can be connected to the first bus, and data communication can be performed between the master device and the slave devices using the first bus. Data requests can only be sent from the master device to the slave devices, and after receiving the request, the slave devices return corresponding response data to the master device. This process can realize one-to-many access.

[0053] Furthermore, by using a multi-master / multi-slave mode bus to communicate data between the operating systems, it is possible to facilitate each operating system to spontaneously send data requests based on demand. On the other hand, since the hardware controller mainly controls the corresponding hardware based on the control of the operating system, communication is performed between the operating systems and the hardware controller using a one-master / multi-slave mode bus, and all data requests are sent from the operating systems to the hardware controller, thereby improving the efficiency of control of the hardware controller.

[0054] The AHB bus has already been defined in AMBA (Advanced Microcontroller Bus Architecture)2. The AHB bus is primarily used as a high-speed system bus, and is applicable to high-performance, low-power system designs. It can be used to connect high-performance modules, such as a CPU, DMA (Direct Memory Access), and DSP (Digital Signal Processing), as an on-chip system bus for an SoC (System on Chip). In the AMBA protocol, AHB is mainly used for system-level high-bandwidth, high-performance system interconnect design, and has the following characteristics: single clock edge operation, non-three-state implementation, support for burst transmission, support for segment transmission, support for multi-master and multi-slave interconnection modes, configurable 32-bit and 128-bit bus widths, and support for byte, nibble, and word transmission. The AHB system includes three parts: a master module (i.e., master device), a slave module (i.e., slave device), and an infrastructure. All transmissions on the entire AHB bus are sent by the master module and responded to by the slave module. The infrastructure includes an arbiter, a multiplexer from the master module to the slave module, a multiplexer from the slave module to the master module, a decoder, a dummy slave module, and a dummy master module.

[0055] APB is primarily used to connect low-bandwidth peripherals, such as UART (Universal Asynchronous Receiver / Transmitter) and 1284. Its bus architecture does not support multiple master modules like AHB, and the only master module in APB is the APB bridge. Its features are: (1) Capable of operating at high frequencies; (2) The protocol is simple and there is no complicated casing; (3) It is a synchronous bus, and all transactions on the bus (reader / writer operating) depend on the rising edge of the clock. (4) One-master, multi-slave. Generally, the APB is connected to the AHB bus system, and the AHB-APB Bridge converts transactions between the AHB bus systems. At this time, the Bridge is the APB master, and all other peripheral devices are slaves. (5) The interface is simple, and is relatively simple compared to AXI (Advanced eXtensible Interface) and AHB. (6) Low power consumption (7) The ability to connect multiple peripheral devices, for example, peripheral devices that can be controlled by the aforementioned hardware controller.

[0056] For the APB bus, a data request can only be sent from the master to the slave, and after the slave receives the request, it returns the corresponding response data to the master. This process can realize one-to-many access, and the access does not involve arbitration or decoder analysis operations on the AHB bus. Here, the AHB bus has high bandwidth characteristics and is used to interconnect high-performance modules (CPU, DMA, etc.) in a system, while the APB bus has a relatively low bandwidth and is used to connect peripheral devices (UART, I2C, etc.) in a system. The AHB bus logic circuit and bus protocol are complex, while the APB bus interface circuit and bus protocol are relatively simple.

[0057] Here, the above chip may be a BMC chip, which may be a SOC chip based on ARM (Advanced RISC Machine) multi-core architecture, integrating multiple peripheral hardware IPs (Intelligent Peripherals), and the BMC chip is disposed on a main board (server motherboard).

[0058] Alternatively, the first operating system may be an operating system with clear and definite time constraints based on response time constraints, where all processing (task scheduling) must be completed within the specified time constraints; otherwise, the system will fail and may be called a real-time operating system (RTOS). The second operating system does not have this characteristic and generally employs a fair task scheduling algorithm, whereby CPU time must be shared as the number of threads / processes increases, and task debugging is non-deterministic. It may be called a non-real-time operating system, such as the Linux (registered trademark) system (officially known as GNU / Linux) or the Windows system. The Linux system is a freely propagating Unix-like operating system based on the POSIX (Portable Operating System Interface) that supports multi-user, multi-tasking, multi-threading, and multi-CPU. The Windows system is an operating system developed based on a graphical user interface and is primarily used in computers, smartphones, and other devices.

[0059] For example, take an ARM architecture processor chip as an example. This processor chip may be an ARM processor, which includes a multi-core CPU, and can run an RTOS system on CPU core 0, and a Linux system on CPU cores (1, N) (N≧2, the total number of processor cores included in the processor is N+1). (Windows or other operating systems can also be run.)

[0060] In this embodiment, when the second operating system is not started, restarted, or cannot control the operating state of the target device, the first operating system controls the hardware controller of the target device via the first bus to control the operating state of the target device. The target device here may be a fan or other device that needs to run when the system starts up. For a fan, the corresponding hardware controller is a fan controller, such as a PWM (Pulse Width Modulation) controller or a FanTach (fan speed) controller. Using the first operating system (e.g., an RTOS system) instead of a conventional CPLD, EC chip, or customized chip reduces hardware costs and provides greater scalability by controlling the device through software.

[0061] For example, a dual system of an RTOS system and a Linux system can be realized based on a BMC dual core, and a fan can be realized based on the multi-core dual system. By utilizing the high real-time characteristics of the RTOS system, during the startup process of the Linux system, the RTOS system can control the fan instead of the CPLD, EC chip, or customized chip, that is, take over the control of the fan and control the operating status of the fan at a sufficiently fast speed. Step S204: Guide the processor to start a second operating system on a second processor core of the processor.

[0062] When the system is powered on or the second operating system is restarted, the second operating system can be run on the second processor core by guiding the processor to start the second operating system on the second processor core. Here, starting the second operating system on the second processor core means scheduling the second processor core to the second operating system, and the system files or mirror files of the operating system may be stored in a memory unit on the chip where the processor is located or off-chip, for example, an external RAM (Random Access Memory). Step S206: After the second operating system is started, the second operating system takes over the control of the target device by taking over the hardware controller via the first bus.

[0063] After the second operating system has finished starting up, the first operating system can always control the operating state of the target device. Considering the need for data interaction between multiple operating systems when running on a multi-core processor and the need to easily control the entire device with one operating system, the second operating system may take over control of the target device. For example, the second operating system may take over the hardware controller via the first bus. The second operating system may take over control of the target device by sending a device takeover request to the first operating system after the second operating system has started up, for example, by sending an interrupt request via the second bus. The first operating system may receive the device takeover request sent by the second operating system and transfer control of the target device to the second operating system, or may perform an operation related to the transfer of control of the target device, such as stopping the operation of a service (process) for controlling the operating state of the target device. For example, after the Linux system is fully started, the RTOS system hands over the control of the fan to the Linux system, which then controls the fan. The above process can be performed after the system is powered on, that is, adopting the startup method of a multi-core dual system, the RTOS system is started first, which contributes to its earlier participation in controlling the fan; after the Linux system is fully started, the RTOS system hands over the control of the fan to the Linux system.

[0064] It should be noted that a server must have at least the characteristics of high scalability and high stability. Since a company's network is unlikely to remain unchanged for a long period of time, and with the development of network information, if a server does not have a certain level of scalability, it will affect the use of the server within the company and ultimately the company's future growth. Therefore, scalability is the most basic characteristic required of a server, and as long as it has relatively high scalability, it can ensure better future use. Scalability includes not only hardware scalability but also software scalability. Since the functions of a server are much more complex than those of a computer, not only the hardware configuration but also the software configuration is very important. To achieve more functions, complete software support is required.

[0065] In addition, because the server needs to process a large amount of data to support the continuous operation of the service, the server also has another very important characteristic, namely, high stability. If the server's data transmission cannot be performed stably, it will have a significant impact on the performance of the service.

[0066] The technical solution of the present application takes advantage of the high scalability of the server and introduces dual software systems, namely a first operating system and a second operating system, to generate hardware interface signals, and hardware devices such as a GPLD and BMC chip, which are used to adjust the transmission voltage of the hardware interface signals and monitor the operating status of other devices within the server. Furthermore, the present application adopts a method of generating a hardware interface signal corresponding to a request command using the first operating system, which first obtains the request command using the first operating system, then determines a plurality of logic bit information corresponding to the request command, and finally generates the hardware interface signal corresponding to the request command based on the plurality of logic bit information and a timer. As can be seen from the above, by using the first operating system to generate a hardware interface signal corresponding to the request command, the present application achieves the technical effect of using a software method to generate a hardware interface signal through simulation, and achieves the purpose of eliminating the need for the chip itself to have hardware logic design for the related hardware interface signals, thereby reducing not only the difficulty but also the cost of chip design. The present application achieves the purpose of using a software system to generate hardware interface signals without the need for hardware logic design of hardware interface signals for the chip, thereby reducing the difficulty of chip design and solving the problem in related technologies that the chip itself needs to have a hardware logic design of the controller, resulting in relatively high chip design costs.

[0067] In addition, the introduction of a dual software system consisting of a first operating system and a second operating system can further ensure the stability of the server. Since the service response speed of the second operating system is slower than that of the first operating system, the first operating system, which has a faster service response speed, is used to generate hardware interface signals, ensuring that the generation of hardware interface signals is not interrupted and that the hardware interface signals are output continuously and stably.

[0068] In the above steps S202 to S206, the first operating system running on the first processor core of the processor controls the hardware controller of the target device via the first bus, thereby controlling the operating state of the target device, wherein the embedded system includes a first operating system and guides a second operating system to start on the second processor core of the processor, wherein the embedded system further includes a second operating system, the response speed of the first operating system is higher than that of the second operating system, the first operating system and the second operating system communicate via a second bus, the bandwidth of the second bus is higher than that of the first bus, and after the second operating system is started, the second operating system takes over the hardware controller via the first bus, thereby taking over control of the target device, thereby solving the problem in the related art that the operating system startup control method requires the addition of an additional chip, resulting in high device costs, reducing hardware costs, and improving device control scalability.

[0069] In one exemplary embodiment, before the first operating system running on the first processor core of the processor controls the hardware controller of the target device via the first bus, the method further includes the following steps: S11: After the chip on which the processor is located is powered on, the first processor core is woken up by the processor.

[0070] S12: Guiding the first operating system to start up on the first processor core by running a boot loader program of the first operating system by the first processor core. The entire system may be divided into two stages, an initial startup stage and a real-time operation stage, according to the operation period, and the startup control method in this embodiment may be performed in the initial startup stage or the real-time operation stage. For the initial startup stage, the initial startup stage begins after the system is powered on, and the chip on which the processor is located is powered on. After the system is powered on, one core is woken up to perform a guide operation for the operating system, and the remaining cores are temporarily in a sleep state, and the woken up core may be the first processor core.

[0071] Optionally, after being powered on, the system first executes one preset core scheduling policy (startup guide policy), i.e., executes the core scheduling policy by one processor core of the processor, the core scheduling policy may be stored in the RAM or Norflash (non-volatile flash memory) of the SOC on-chip, and this scheduling policy may be flexibly arranged according to different design needs, its main functions include specifying the initial processing resources (processor cores) that need to be run by different operating systems and determining the guide process of the heterogeneous operating system, and powering on the chip may mean powering on the SOC chip level.

[0072] Alternatively, the chip may be a BMC (Baseboard Management Controller, a management control chip in a server platform) chip, which means an SOC chip based on an ARM multi-core architecture, integrating multiple peripheral hardware IPs (Intelligent Peripherals, smart external devices), and the BMC chip is located on the main board (server motherboard), and powering on the chip means powering on the SOC chip level.

[0073] After waking up the first processor core, a boot loader program may guide the first processor core to run a first operating system, and the first processor core may guide the first operating system to start on the first processor core through the boot loader program. The boot loader program may be located in a personal computer or other computer application and refers to a program for guiding the loading of an operating system, for example, a specific program in a Boot ROM, where the specific program refers to code that guides the starting of an operating system and belongs to the Boot Loader program. The Boot ROM is a small block of mask ROM (Read-Only Memory) or write-protected flash memory in a CPU-on-chip embedded processor chip.

[0074] According to this embodiment, in the initial startup stage, the boot loader program guides the operating system to start on the corresponding processor core, thereby improving the success rate of the operating system startup and preparing for the real-time operation stage. In one exemplary embodiment, controlling a hardware controller of a target device via a first bus by a first operating system running on a first processor core of a processor includes the following steps.

[0075] S21: Execute a first control task of a first operating system on a first processor core, where the first control task is used to control a hardware controller. S22: The first processor core reads sensor data from a predetermined sensor corresponding to the target device. S23: The first control task sends an equipment control command to the hardware controller via the first bus based on the sensor data of the specified sensor, and the hardware controller controls the operating state of the target equipment in accordance with the equipment control command.

[0076] In this embodiment, controlling the hardware controller of the target device by the operating system may be performed by controlling the hardware controller by a control task (service) on a processor core run by the operating system, where the control task may refer to a corresponding control task. For the hardware controller of the target device, a first control task (first control process) of a first operating system may be executed on a first processor core, and the first control task controls the hardware controller.

[0077] The hardware controller may be controlled based on sensor data from a sensor. Parameters affecting the operation of different target devices may differ, and the sensor data that needs to be acquired may differ accordingly. The target device may be a device that operates immediately after the chip is powered on, and the corresponding sensor is a predetermined sensor. The predetermined sensor may be of various types, including, but not limited to, at least one of a temperature sensor, a humidity sensor, a noise sensor, etc. Since the first control task runs on the first processor core, the first processor core may read the sensor data from the predetermined sensor. The sensor data from the predetermined sensor may be stored in a memory space within the predetermined sensor or transmitted by the predetermined sensor to the memory space. In this embodiment, the location where the sensor data from the predetermined sensor is read is not limited.

[0078] The read sensor data of the predetermined sensor may be sensor data within one time period, all sensor data after the target device is started, or sensor data that satisfies other time limit conditions. After acquiring the sensor data of the predetermined sensor, the first control task can control the operating state of the target device based on the sensor data of the predetermined sensor. Controlling the operating state of the target device may be achieved by having the first control task send a device control command to a hardware controller of the target device, and the hardware controller controls the operating state of the target device according to the device control command.

[0079] Alternatively, the first control task may determine a desired operating state of the target device based on sensor data from a predetermined sensor, and if the current operating state of the target device differs from the desired operating state, may generate the device control command, which may control the target device to adjust the operating state to the desired operating state. The device control command may be transmitted to a hardware controller of the target device via a first bus. The first bus is the same as in the above-described embodiment, and therefore will not be described further here.

[0080] According to this embodiment, the sensor data of a predetermined sensor is read, and the target device is controlled based on the sensor data, and the operating state of the device is controlled, thereby improving the utilization rate of resources. In one exemplary embodiment, transmitting, by the first control task, an equipment control command to a hardware controller via a first bus based on sensor data of a predetermined sensor includes the following steps:

[0081] S31: Determine a target parameter value of an equipment operation parameter of a target equipment based on sensor data of a predetermined sensor through a first control task, where the equipment operation parameter is a parameter for controlling the operation state of the target equipment. S32: The first control task sends an equipment control command including a target parameter value to the hardware controller via the first bus.

[0082] In this embodiment, the first control task may determine a desired operating state of the target equipment based on sensor data from a predetermined sensor. The desired operating state may be represented by a parameter value of an equipment operating parameter, and the equipment operating parameter may be a parameter that controls the operating state of the target equipment. Different types of equipment may have different corresponding equipment operating parameters. For example, for a fan, the corresponding equipment operating parameter may be the rotation speed, and for other types of equipment, the corresponding equipment operating parameter may be another operating parameter. The desired operating state may correspond to a target parameter value of the equipment operating parameter of the target equipment.

[0083] After determining the target parameter value of the equipment operating parameter of the target equipment, the target parameter value may be included in the above-mentioned equipment control command, i.e., the first control task sends an equipment control command including the target parameter value to the hardware controller, and the manner of sending the equipment control command to the hardware controller is the same as in the above-mentioned embodiment, so no further description will be given here.

[0084] According to this embodiment, the parameter values ​​of the equipment operation parameters of the target equipment are determined based on the sensor data, and the determined parameter values ​​are included in the equipment control command, thereby improving the accuracy of equipment control. In one exemplary embodiment, determining, by the first control task, a target parameter value for an equipment operating parameter of a target equipment based on sensor data of a predetermined sensor includes the following steps:

[0085] S41: If the target device is a fan, a first control task determines a target parameter value of a fan operation parameter of the fan based on sensor data of a predetermined sensor. In this embodiment, the target device may be a fan, which may be a fan for dissipating heat from a server or other device located therein, i.e., a heat dissipation fan. In this case, the device operating parameters may be fan operating parameters, which may include one or more of the following, including but not limited to at least one of the rotation speed, rotation period, and period switching time, and may also be other operating parameters. This embodiment is not limited thereto.

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

[0087] According to this embodiment, by controlling the operation state of the fan, for example, in the case of powering on the system, restarting the system, or other scenarios, the operation state of the fan can be quickly controlled, thereby improving the immediacy of fan control.

[0088] In one exemplary embodiment, when the target equipment is a fan, determining, by the first control task, a target parameter value of a fan operation parameter of the fan based on sensor data of a predetermined sensor includes the following steps: S51: If the target device is a fan and the specified sensor is a temperature sensor, a first control task determines a target rotational speed value of the fan based on sensor data of the temperature sensor, where the fan rotational speed has a positive correlation with the temperature detected by the temperature sensor.

[0089] In a scenario where the target device is a fan, the predetermined sensor may be a temperature sensor, the number of the temperature sensors may be one or more, the installation positions of the temperature sensors may be arranged as needed, and different temperature sensors may be installed at different positions. Optionally, the sensor data of the temperature sensor is used to represent the temperature detected by the temperature sensor, and the first control task can determine a target rotational speed value of the fan based on the sensor data of the temperature sensor, where the fan rotational speed has a positive correlation with the temperature detected by the temperature sensor.

[0090] In the case where there are multiple temperature sensors, the maximum temperature detected by the multiple temperature sensors may be determined based on the sensor data of each temperature sensor, and the fan rotation speed may be determined based on the maximum temperature detected by the multiple temperature sensors. Determining the fan rotation speed based on the average temperature detected by the multiple temperature sensors can ensure safety of equipment operation. In a scenario where there are multiple fans, the rotation speed of each fan may be determined based on the maximum or average temperature detected by the temperature sensor corresponding to each fan.

[0091] For example, instead of a processing unit such as a CPLD, EC chip, or customized chip, the first operating system (e.g., an RTOS system) may be used to control the fan speed (fan control may be performed in real time by a BMC). Immediately after the system is powered on, a first processor core (e.g., CPU0, which may be woken up by hardware) may be woken up, and the first processor core may run a boot loader program (e.g., a predetermined program in BootROM) to load the startup of the first operating system. The first processor core may then read data from various temperature-related sensors to perform fan control (e.g., fan speed control), fully simulating the processing unit and achieving the function of cooperative fan control. When controlling the fan speed, the first operating system may calculate a PWM value based on the temperature sensor and adjust the fan speed. In this manner, the first operating system can control the fan speed during the startup process of the second operating system.

[0092] For example, the hardware of a fan controller is shown in FIG. 3. The multi-core processor includes CPU0 through CPUN. The multi-core processor normally runs system service programs. Because the Linux system runs a relatively large number of system service programs, a relatively large number of CPU cores are initially assigned. The core initially assigned to the RTOS system is CPU0, and the cores initially assigned to the Linux system are CPU1 through CPUN. Immediately after the system is powered on, CPU0 is woken up, a predetermined program in BootROM is executed by CPU0, and the RTOS system startup is loaded. CPU0 reads various temperature-related sensor data via an IIC (Inter-Integrated Circuit, integrated circuit bus) and controls the rotation speed of a brushed fan (or brushless fan) via a brushed controller (or brushless controller). Here, the relationship between the first bus, the second bus, and the IIC may be such that the first bus may be a bus subordinate to the second bus, and the IIC may be a bus subordinate to the first bus. A bus subordinate to a bus may refer to a bus connected to that bus.

[0093] According to this embodiment, instead of adding an additional processing unit, the operating system running on the processor core is used to control the fan rotation speed, thereby ensuring control over the fan and reducing the operating costs of the system. In one exemplary embodiment, directing the launch of a second operating system on a second processor core of the processor includes the following steps.

[0094] S61: The second processor core is woken up by the second program loader by executing the second program loader by the first processor core. S62: Guide the second operating system to start on the first processor core by running a generic boot loader of the second operating system by the second processor core.

[0095] In this embodiment, when starting the operating system, a second program loader (referred to as Second Program Loader, SPL for short) may be loaded into an internal memory, for example, a static random-access memory (SRAM) inside the SOC, while the SPL may be responsible for loading a universal boot loader program (referred to as Universal Boot Loader, U-Boot for short) into a random-access memory (RAM for short), and the second program loader may guide the loading of the second operating system or the loading of the first operating system.

[0096] For the second operating system, the second program loader may be executed by the first processor core, which may wake up the second processor core, and the second processor core may run a generic boot loader (general purpose boot loader program) for the second operating system, thereby guiding the second operating system to start on the first processor core. Here, the second program loader may guide the loading of a boot program for the second operating system, which may include the generic boot loader.

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

[0098] For example, after the system is powered on, the processor first wakes up the CPU0 core so that the RTOS system can run as quickly as possible, and then guides the RTOS system to start using the program in BootROM. During the RTOS system startup process, it continues to load U-Boot through SPL and guides U-Boot to start the second operating system on CPU1 until the Linux system is successfully started.

[0099] Boot ROM is a program fixed in the internal ROM of a chip (such as an SOC chip), which is the uboot guide code. Boot ROM reads the hardware startup information (such as the dial switch settings) and reads the uboot-spl code (i.e., SPL) from the specified startup medium (such as SD, MMC, etc.). SPL is mainly responsible for initializing the external RAM and environment, and then loading the true uboot mirror into the external RAM for execution. The external RAM can be DDR (Double Data Rate Synchronous Dynamic Random-Access Memory) or other RAM. According to this embodiment, the second processor core is woken up by the second program loader, and a generic boot loader program is run by the second processor core to guide the second operating system to start on the corresponding processor core, thereby improving the convenience and success rate of starting the operating system.

[0100] As a selective example, the startup process of a multi-core dual system will be explained below by taking an RTOS system and a Linux system as examples. In order to take over the fan management as quickly as possible, the RTOS system may be started as soon as possible, and the Linux system may take over the fan control after the startup of the Linux system is completed. As shown in Figure 4, the startup process of the multi-core dual system may include the following steps:

[0101] Step 1: Wake up CPU0 immediately after the system is powered on. Step 2: CPU0 runs a program in BootROM and loads it to start the RTOS system. Step 3: In the startup process of the RTOS system, wake up CPU1 to guide u-boot and start the fan control program (FanCtrl_RTOS_APP) in the first operating system.

[0102] Step 4: Guiding u-boot by CPU1 may include an SPL stage and a Uboot stage, and proceeds to the SPL stage by calling SPL. Step 5: In the SPL stage, SPL guides Uboot to start. Step 6: In the Uboot stage, the Linux cores (CPU1 to CPUN) are loaded, and the BMC service program and the fan control program (FanCtrl_Linux_APP) in the second operating system are started.

[0103] According to this example, in the startup and operation process of the dual system, the RTOS system is started first to control the fan, and after the Linux system is started, the second operating system takes over control of the fan, thereby ensuring that the fan can be controlled quickly when the system is powered on and improving the efficiency of fan control.

[0104] In one exemplary embodiment, taking over the hardware controller via the first bus by the second operating system includes the following steps: S71: Sending a first inter-core interrupt by the second operating system to the first operating system via the second bus, where the first inter-core interrupt is used to request that the second operating system take over the hardware controller.

[0105] S72: When the first operating system receives a second inter-core interrupt in response to the first inter-core interrupt to indicate consent to the second operating system taking over the hardware controller, a second control task of the second operating system controls the hardware controller via the first bus, wherein the second control task is used to control the hardware controller.

[0106] In this embodiment, the control of the target device can be transferred between different operating systems by using an inter-core interrupt, such as an SGI (Software Generated Interrupt, a software-triggered interrupt, which is an inter-core interrupt in a Linux system). One operating system can request another operating system to take over the hardware controller of the target device by issuing an inter-core interrupt (IPI) to another operating system, thereby obtaining control of the target device. Unlike ordinary interrupts from external devices, an IPI is an interrupt triggered between multiple cores within an SOC, and each core reserves a dedicated set of interrupt numbers for the IPI. For example, in the ARM64 architecture, the reserved interrupt numbers are 16, from 0 to 15.

[0107] When the second operating system needs to take over a hardware controller of the target device, it can request the second operating system to take over the hardware controller by sending a first inter-core interrupt to the first operating system, and the first inter-core interrupt can be sent via a second bus. After receiving the first inter-core interrupt, the first operating system can determine whether to allow the second operating system to take over the hardware controller, and if so, can send a second inter-core interrupt back to the second operating system, and the second inter-core interrupt is used to indicate consent to the second operating system taking over the hardware controller.

[0108] After receiving the second inter-core interrupt, the second operating system can control the hardware controller through a second control task, the second control task is used to control the hardware controller, and the control of the hardware controller by the second control task may be realized via the first bus. The second control task may be established before sending the first inter-core interrupt or after receiving the second inter-core interrupt, and this embodiment is not limited thereto.

[0109] For example, after completing the startup of the Linux system, CPU1 begins sending an IPI interrupt to CPU0 requesting that it take control of the fan. According to this embodiment, it is possible to transfer the control right of the target device between different operating systems by using an inter-core interrupt, thereby improving the reliability of device control.

[0110] In one exemplary embodiment, after sending the first inter-core interrupt by the second operating system to the first operating system via the second bus, the method further includes the following steps: S81: In response to the acquired first inter-core interrupt, control a third control task of the first operating system to sleep, where the third control task is used to control a hardware controller. S82: If the third control task has already gone to sleep, send a second inter-core interrupt by the first operating system to the second operating system via the second bus.

[0111] In this embodiment, for the first operating system, the task for controlling the hardware controller of the target device is a third control task, which may be the first control task described above, and the logic for controlling the hardware controller is the same as in the above embodiment. After receiving the first inter-core interrupt, the first operating system can control the third control task to sleep, thereby avoiding device control confusion caused by the existence of control tasks for controlling the hardware controller in both operating systems.

[0112] After the third control task has already gone to sleep (i.e., the third control task is in a sleep state), the first operating system may send the above-mentioned second inter-core interrupt to the second operating system, and this second inter-core interrupt may be sent via the second bus. For example, after receiving the IPI interrupt sent by CPU1, the RTOS system will start putting the related services on the RTOS system to sleep one after another. After the related services on the RTOS system are completely asleep, CPU0 will send an IPI interrupt to CPU1 to notify CPU1 that it can take control of the fan.

[0113] According to this embodiment, the corresponding control task can be put to sleep based on the received inter-core interrupt, and after the corresponding control task has gone to sleep, the device control rights can be transferred by the inter-core interrupt, thereby improving the reliability of device control. In one exemplary embodiment, the method further includes the following steps: S91: If the third control task has already gone to sleep, push system operation data of the first operating system onto a stack, where the second inter-core interrupt is further used to instruct the second operating system to take over the first processor core.

[0114] In this embodiment, when the second operating system is unable to control the operating state of the target device, the first operating system can temporarily control the operating state of the target device. In this case, all tasks running in the first operating system are tasks related to controlling the operating state of the target device, such as the third control task. If the third control task has already gone to sleep when the second operating system is able to control the operating state of the target device, no service process may be running in the first operating system, and the first processor core will not be effectively utilized.

[0115] For example, during the startup process of a Linux system, the RTOS system has control of the fan. After Linux starts up normally, it takes over control of the fan from the RTOS system. At this time, no service processes are running on the RTOS system, and the CPU0 core resources are not being used effectively. In this embodiment, a resource reclaim mechanism may be adopted for the processor core (e.g., CPU0 core) of the first operating system, and when the third control task has already gone to sleep, the fields of the first operating system may be saved, i.e., the system operation data of the first operating system may be pushed onto the stack. At the same time, a second inter-core interrupt may be issued to instruct the second operating system to take over the first processor core.

[0116] For example, a resource reclaim mechanism for CPU0 may be adopted. After the Linux system is fully started (started on CPU1...CPUN), the RTOS system hands over control of the fan to the Linux system, releasing CPU0 to be scheduled by the Linux system. CPU0 puts the RTOS system to sleep, releases all current services, pushes running data onto a stack, and joins a queue run by the Linux operating system to be scheduled by the Linux system, thereby achieving the goal of improving CPU resource utilization. For the Linux system, after the Linux system takes over control of the fan, the RTOS system may put the RTOS system to sleep, releases CPU0, and reclaims it, allowing CPU0 to be scheduled normally by the Linux system, achieving the goal of all CPU cores providing services to the Linux system, saving resources, and improving CPU resource utilization.

[0117] According to this embodiment, a processor core resource recovery mechanism is adopted, and after the second operating system takes over control of the target device, the data of the first operating system running on the processor core of the first operating system is pushed to a stack, and the processor core of the first operating system is released to the second operating system, thereby improving the resource utilization rate of the processor core.

[0118] As a selective example, the process of invoking fan control rights through an inter-core interrupt will be explained below using an RTOS system and a Linux system as examples. As shown in Figure 5, after the Linux system triggers an interrupt requesting to take over fan control, the FanCtrl_RTOS_APP process completes its current processing, and the RTOS system pushes the system operation data onto the stack. Then, it returns an interrupt agreeing to take over fan control, and the Linux system takes over CPU0 core. The FanCtrl_Linux_APP process is assigned to run on CPU0 core or another CPU core of the Linux system according to a scheduling balance algorithm.

[0119] According to this selective example, the fan control right is inferred by an inter-core interrupt, which improves the convenience of information inference and the reliability of device control. In one exemplary embodiment, after the second operating system takes over the hardware controller via the first bus, the method further includes the following steps:

[0120] S101: When the second operating system is to be restarted, the second operating system wakes up the first operating system via the second bus, and the first operating system takes over the hardware controller via the first bus, thereby taking over control of the target device. S102: Control the second operating system to restart the system. In this embodiment, when a restart is required due to reasons such as a system down or receiving a reboot command, the second operating system can take over control of the target device by first waking up the first operating system and having the first operating system take over the hardware controller. The first operating system may be woken up via the second bus, and the first operating system may take over the hardware controller via the first bus.

[0121] According to this embodiment, when a restart occurs in the second operating system, the first operating system is woken up to take over control of the target device, thereby improving the reliability of device control. In one exemplary embodiment, when attempting to restart the second operating system, waking up the first operating system via the second bus by the second operating system includes the following steps: S111: When the second operating system is to be restarted, the second operating system sends a system wake-up interrupt to the first operating system via the second bus to wake up the first operating system.

[0122] In this embodiment, the first operating system may be woken up by an inter-core interrupt. When the second operating system is to be restarted (e.g., after the system goes down or a reboot command is received), the second operating system may wake up the first operating system by sending a system wakeup interrupt to the first operating system. This system wakeup interrupt may be a voluntary wakeup interrupt. After the first operating system takes over the hardware controller, the second operating system may be controlled to restart the system; meanwhile, after the second operating system is restarted, the hardware controller may be taken over again. The process of taking over the hardware controller is the same as in the previous embodiment and will not be further described here.

[0123] For example, as shown in FIG. 6, in the fan control workflow, when a restart (system down, reboot command) occurs in the Linux system, a spontaneous wake-up interrupt is sent, and after the restart occurs in the Linux system, the fan control flow may include the following steps: Step S602: The Linux system restarts due to reasons such as system down or receiving a reboot command.

[0124] Step S604: The Linux system triggers a spontaneous wake-up interrupt. Step S606: The RTOS system is woken up, and the RTOS system takes over the control of the fan. Step S608: Execute the Linux system restart process.

[0125] According to this embodiment, the operating system is spontaneously woken up by an inter-core interrupt, which improves the convenience and reliability of waking up the operating system. The following provides an explanation of the startup control method for an embedded system in an embodiment of the present application, in conjunction with a selective example, in which the first operating system is an RTOS system, the second operating system is a Linux system, and the target device is a fan.

[0126] This example provides a technical solution for real-time fan control in a multi-core dual system. As shown in FIG. 7, the flow of the startup control method for the embedded system in this example may include the following steps: Step 1: In the T0-T1 phase, the system starts to be powered on, CPU0 is woken up by the hardware and starts executing the code of the RTOS system part, and also wakes up CPU1 so that it can participate in the u-boot startup process.

[0127] Step 2: From time T1, the woken up CPU1 starts executing the u-boot part of the code, starts initializing some hardware-related data, and guides the Linux operating system to start up. Meanwhile, the task related to fan control in the RTOS system on CPU0 continues to run until time T5. Step 3: From time T2, the Linux operating system begins to boot.

[0128] Step 4: At time T3, the startup of the Linux system is completed, and CPU1 starts sending an IPI interrupt to CPU0 to request control of the fan, causing CPU0 to stop services related to the RTOS system and run service code related to the Linux system. Step 5: From time T4, the RTOS system receives the IPI interrupt sent by CPU1, and starts to put the related services on the RTOS system to sleep one after another. After the related services on the RTOS system are completely asleep, CPU0 sends an IPI interrupt to CPU1 to notify CPU1 that CPU1 can take control of the fan and that CPU0 can participate in the service operation on the Linux system side.

[0129] At this point, from time T5, CPU0 is reclaimed by the Linux system, the entire system changes to the multi-core single system operating mode, and all subsequent code runs normally. According to this selective example, the purpose of controlling the fan is achieved by multiplexing one CPU core instead of using hardware, improving the utilization rate of the CPU core resources, without requiring additional cost increases, and also having excellent scalability.

[0130] In one exemplary embodiment, Allocating the allocation target services of one group to corresponding operating systems in the embedded system according to a resource dynamic allocation rule, where the resource dynamic allocation rule includes performing resource dynamic allocation based on at least one of service response speed, service resource occupancy rate, service coupling degree, and service importance, and the embedded system includes a first operating system and a second operating system; determining a resource allocation result corresponding to the assigned services of the group, wherein the resource allocation result is used to indicate a processing resource of the processor corresponding to each assigned service of the assigned services of the group, the processing resource of the processor including a processor core; A method of allocating processor processing resources to a first operating system and a second operating system based on the operating system corresponding to each service to be allocated and the resource allocation results can be adopted to allocate operating services and processing resources to each operating system, but is not limited to these methods.

[0131] In the processor's running process, a group of services to be assigned, i.e., services to be assigned to a first operating system and a second operating system, may be obtained. Because different services to be assigned may have different dimensions, such as response speed, service resource occupancy, service coupling with other services, and service importance, a dynamic resource allocation rule may be pre-configured. The dynamic resource allocation rule may include a rule for allocating services, and assigning the services to the corresponding operating systems to execute the assigned services using the processing resources of the corresponding operating systems. Optionally, the dynamic resource allocation rule may include dynamic resource allocation based on at least one of service response speed, service resource occupancy, service coupling, and service importance. Different allocation rules may have corresponding priorities, such as service importance, service coupling, service response speed, and service resource occupancy, in descending order of priority. According to the dynamic resource allocation rule, a group of services to be assigned (or tasks to be assigned; different services to be assigned may correspond to different processes) may be assigned to corresponding operating systems in the embedded system, and a service allocation result may be obtained.

[0132] Alternatively, the first operating system may be an operating system with a clear and specific time constraint based on response time constraints, where all processing (task scheduling) must be completed within the specific time constraints, otherwise the system will fail. It may be a real-time operating system, such as FreeRTOS, RTLinux, or other real-time operating systems in embedded systems. The second operating system does not have this characteristic. It generally employs a fair task scheduling algorithm, and as the number of threads / processes increases, CPU time must be shared. Task debugging is non-deterministic. It may be called a non-real-time operating system, such as Contiki, HeliOS, Linux, or other non-real-time operating systems in embedded systems.

[0133] Accordingly, the services assigned to the first operating system are generally real-time services, which refer to services that need to be scheduled within a certain time frame and must be processed by a processor at a sufficiently fast speed so that the processing results can control the production process or respond quickly to the processing system within a certain time frame. A typical scenario is industrial control, where control of a robot hand is a real-time service, and the system must take prompt action before detecting a malfunction of the robot hand, otherwise serious consequences may occur. The services assigned to the second operating system are generally non-real-time services, which refer to services that are not sensitive to scheduling time and have a certain tolerance for scheduling delays, such as reading sensor data from a temperature sensor in a server.

[0134] 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 can control the production process or respond quickly to the processing system with the processing results within a predetermined time, schedule all available resources to complete real-time services, and control all real-time services to run in a coordinated manner, and is characterized by timely response and high reliability.

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

[0136] After each service to be assigned is assigned to a corresponding operating system, processing resources corresponding to each service to be assigned can be assigned based on the service assignment result, thereby obtaining a resource assignment result corresponding to the services to be assigned in one group. When assigning processing resources to the services to be assigned, the processing resources of the first operating system can be assigned to the service assigned to the first operating system, and the processing resources of the second operating system can be assigned to the service assigned to the second operating system. At the same time, in consideration of load balance, if there are unallocated processing resources, the unallocated processing resources can be assigned to some of the services.

[0137] The processing resources of the processor may be dynamically allocated on a time slice basis, or may be allocated to the first operating system and the second operating system on a processor core basis, taking into consideration that the operating systems to which the processing resources belong are frequently switched and the service processing time is not necessarily an integer multiple of the time slice, which may result in an extended response time for some services. That is, the processor cores of the processor are allocated to the corresponding operating systems on an entire processor core basis, the number of processor cores allocated to each operating system is an integer, and the processor cores allocated to different operating systems are different from each other.

[0138] Optionally, a dynamic resource allocation module may determine resource allocation results corresponding to the services to be allocated in a group. As shown in FIG. 8, the dynamic resource allocation module may be a software module running on the first operating system or the second operating system. For example, when running on the second operating system, the dynamic resource allocation module may be implemented by a software module in the second operating system, which can dynamically allocate processing resources for services based on the output of the service management module. Here, the software module may be a program module with pre-configured functions. For example, the dynamic resource allocation module may be a program module with a dynamic resource allocation function, and the service management module may be a program module with a service management function. Each software module can be configured and adjusted as a whole and can be applied in various application engineering.

[0139] The processor's processing resources may be allocated to the first operating system and the second operating system based on the operating systems corresponding to each of the services to be allocated and the resource allocation results. Optionally, unallocated processing resources of the processor may be allocated to the corresponding operating systems, and the unallocated processing resources may be determined based on the correspondence between the unallocated processing resources and the services to be allocated and the correspondence between the services to be allocated and the operating systems.

[0140] Optionally, as shown in Figure 8, a resource adaptive scheduling module (e.g., a core adaptive scheduling module) may allocate the processor's processing resources to the first operating system and the second operating system. This resource adaptive scheduling module may be a software module running on the first operating system or the second operating system. For example, when running on the second operating system, the resource adaptive scheduling module may be realized by software in a Linux system. The actual scheduling operation of the processor's processing resources (e.g., processor hard core resources) can be completed based on the output of the service management module and the output of the resource dynamic allocation module. For example, through resource scheduling by the core resource adaptive module, M cores out of the (M+N) cores are scheduled to the real-time operating system, and N cores are scheduled to the non-real-time operating system.

[0141] For example, heterogeneous operating systems (heterogeneous operating systems) may run on different cores of the same processor, providing the entire processor system with the ability to process real-time and non-real-time services in parallel, and by adaptively adjusting the processor core resources (e.g., processor cores) occupied by different operating systems, significantly improving processor resource utilization. Here, "heterogeneous" means that different types of operating systems run on the same multi-core processor of an embedded system, and "multi-system" means that multiple operating systems run on the same multi-core processor of an embedded system, and these operating systems run simultaneously in the time dimension.

[0142] Optionally, the process further includes generating a rule structure by reading the rule profile, where the rule structure is used to record a resource dynamic allocation rule. The dynamic resource allocation rules may be configured based on a rule profile, and a rule structure for recording the dynamic resource allocation rules may be generated based on the read rule profile. Here, the rule profile may be a load balance policy file (payload_balance.config), which may be used to configure classification methods for various running services (or processes), evaluation principles for real-time levels, etc. In the load balance policy file, the dynamic resource allocation rules may be configured according to different parameters. An example of a load balance policy profile is as follows:

[0143] classification kinds =2 / / If the value is 1, classify the processes according to attributes such as critical and non-critical, otherwise classify the processes according to pre-arranged classification methods (e.g. real-time and non-real-time). real-time grade evaluation=2 / / If the value is 1, the average CPU occupancy rate within the past statistical minutes is used as the process real-time level evaluation principle; otherwise, the pre-assigned priority is used as the process real-time level evaluation principle. statistic minutes =5 / / represents the statistical time (unit: minute) of the average occupancy rate of each process, and is valid when real-time grade evaluation is 1.

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

[0145] The classification method and real-time level evaluation principle are open, allowing users to customize a method or principle. Rules for service management by the service management module may be dynamically configured or additional rules may be configured on top of existing rules. The service management module may configure multiple rules with the same function, but conflicts between rules are avoided. That is, the currently used rule among rules with the same function is determined based on rule selection conditions such as the rule deployment time and rule priority, thereby avoiding conflicts between rules. The profile load_balance.config describes one possible scenario. In the profile, the classification_kinds variable specifies specific classification criteria (e.g., based on service importance or real-timeness) and classification classes (e.g., critical services and general services, real-time services and non-real-time services, etc.). Meanwhile, the real-time_grade_evaluation variable specifies real-time evaluation criteria (e.g., based on the average CPU occupancy rate within the past statistic_minutes or pre-configured service priority). The real-time level type is user-customizable and may be defined as high, normal, or low, or may be further subdivided.

[0146] The output of the load balancing policy module is the deployed classification method, real-time level evaluation principle, etc., and when implemented in software, it can be a specific profile (e.g., load_balance.config file) or a structure variable, and either of these files or structure variables can ultimately be accessed by the service management module to obtain a specific load balancing policy.

[0147] According to this embodiment, the rule profile is read to generate a rule structure, and the dynamic resource allocation rules are recorded, thereby improving the convenience of information allocation. Optionally, the process further includes obtaining a rule update profile through an external interface of the second operating system, where the rule update profile is used to update the already deployed resource dynamic allocation rules; and updating a rule structure using the rule update profile to update the resource dynamic allocation rules recorded in the rule structure.

[0148] The rule structure may be in a fixed format, i.e., it cannot be modified during the operation of the embedded system, or in a flexibly configurable format, i.e., the configuration can be changed according to a profile of a specific format. In this embodiment, a rule update profile may be obtained, which is used to update the dynamic resource allocation rules that have already been configured, and the rule structure can be updated using the rule update profile, thereby updating the dynamic resource allocation rules recorded in the rule structure.

[0149] When updating a rule structure using a rule update profile, a new rule structure may be directly generated based on the rule update profile and the existing rule structure may be replaced with the newly generated rule structure, or the parameter values ​​of the rule parameters indicated by the rule update profile may be used to update the parameter values ​​of the corresponding rule parameters in the rule structure.

[0150] Alternatively, the profile in a specific format may be read by an external interface of the first operating system or the second operating system, and the second operating system may be primarily responsible for dynamic resource scheduling of the embedded system, taking into account the level of service that needs to be processed. When obtaining the rule update profile, the rule update profile may be obtained by an external interface of the second operating system. For example, the load balance policy module may be in a fixed format and may be configured by an external interface of the Linux system, or, for example, a profile (load_balance.config) of the specific format mentioned above may be defined and its configuration may be changed by the file read / write method.

[0151] The external interface is an external interface of the multi-core processor, and may be a network interface, a SPI (Serial Peripheral Interface) controller interface, a UART serial port, or any other path through which data can be acquired from the outside. The hardware used by the file and the specific file location can be read in various implementations. For example, a profile can be loaded from a Web (World Wide Web) interface via a network interface, a profile can be read from an SPI Flash (flash memory) on a board card via an SPI controller, or a profile can be acquired from a serial port data transmission / reception software tool on another PC (Personal Computer) via a UART serial port.

[0152] According to this embodiment, the rule update profile is acquired and the profile update rule structure is updated using the acquired rule, thereby improving the flexibility of the allocation of dynamic resource allocation rules. Alternatively, a method of allocating, among the services to be allocated in one group, those whose service response speed requirements are equal to or greater than a set response speed threshold to a first operating system, and a method of allocating, among the services to be allocated in one group, those whose service response speed requirements are smaller than a set response speed threshold to a second operating system, can be adopted to allocate the services to be allocated in one group to corresponding operating systems in the embedded system based on resource dynamic allocation rules, but the method is not limited to these.

[0153] When allocating a service to be allocated, the service to be allocated may be allocated to a corresponding operating system based on the service response speed requirement of the service to be allocated. The service response speed is used to evaluate the real-time level of the service, and the higher the service response speed requirement, the more sensitive the service is to the scheduling time and response speed of the operating system. The operating system must process services with a high real-time level and high service response speed requirement at a sufficiently fast speed, so that the processing result can control the production process or respond to the processing system quickly within a predetermined time. Meanwhile, services with a lower service response speed requirement have a certain tolerance to scheduling delays.

[0154] For a service to be assigned whose service response speed requirement is equal to or greater than the set response speed threshold, the service is sensitive to the scheduling time and response speed of the operating system and may be assigned to a first operating system (e.g., a real-time service is assigned to a real-time operating system).For a service to be assigned whose service response speed requirement is smaller than the set response speed threshold, the service is not sensitive to the response speed and scheduling time and may be assigned to a second operating system (e.g., a non-real-time service is assigned to a non-real-time operating system).Here, the service response speed requirement may be indicated by a service response speed indication parameter, and the set response speed threshold may be a response speed threshold on the order of milliseconds or seconds, for example, 100 ms, 200 ms, 1 s, etc., and the set response speed threshold is not limited in this embodiment.

[0155] Optionally, when allocating a group of services to be allocated to corresponding operating systems in the embedded system, a first service list corresponding to the first operating system and a second service list corresponding to the second operating system may be output, where the first service list is used to record the services to be allocated to the first operating system and the second service list is used to record the services to be allocated to the second operating system, i.e., the service allocation result includes the first service list and the second service list, and the output first service list and second service list may be used in a dynamic scheduling process of the processor's processing resources.

[0156] For example, suppose that a real-time level classification is performed on system services, a list of real-time and non-real-time services is obtained, and there are a total of 20 services, where the real-time services are Service 1 and Service 2, and the non-real-time services are Service 3 to Service 20.

[0157] Here, the service management module may classify services that are currently being run. When the BMC system is first run, all services that the system is currently running are already known to the system, so the service management module classifies these services once based on the output of the load balancing module. After classification, different services are assigned to different operating systems (RTOS system and Linux system) for execution. During subsequent running processes, if the number of service processes changes (for example, a process hangs up or a new process is started), the service management module continues to perform service classification, and classifies and manages existing services in real time according to the load balancing policy. The service management module may be a resident process in the Linux system, which itself runs all the time and manages and classifies currently running processes.

[0158] According to this embodiment, by allocating the target service to the corresponding operating system in accordance with the service response speed requirement, it is possible to ensure the immediacy of the service response for services that are sensitive to scheduling time. Alternatively, the services to be assigned in one group whose service resource occupancy rate is less than a first occupancy rate threshold may be assigned to a first operating system, and the services to be assigned in one group whose service resource occupancy rate is equal to or greater than a first occupancy rate threshold may be assigned to a second operating system, so that the services to be assigned in one group can be assigned to corresponding operating systems in the embedded system according to dynamic resource allocation rules, but the present invention is not limited to these methods.

[0159] When allocating a service to be allocated, the service can be allocated to a corresponding operating system based on the service resource occupancy rate of the service to be allocated. The service resource occupancy rate can be the average proportion of the processing resource of the service within a unit time (for example, the CPU occupancy rate per minute). A high service resource occupancy rate will affect the response speed of this service and the response speed of subsequent services, so the real-time level of the service can be evaluated based on the service resource occupancy rate. The higher the service resource occupancy rate, the greater the impact on the scheduling time and response speed of the operating system, and the lower the real-time level. On the other hand, for a service with a low service resource occupancy rate, the impact on the scheduling time and response speed of the operating system is not great, and the real-time level is high. For a service to be assigned whose service resource occupancy rate is less than the first occupancy rate threshold, the impact on the scheduling time and response speed of the operating system is small, and such a service to be assigned can be assigned to the first operating system. For a service to be assigned whose service resource occupancy rate is equal to or greater than the first occupancy rate threshold, the impact on the scheduling time and response speed of the operating system is relatively large, and such a service to be assigned can be assigned to the second operating system. Here, the first occupancy rate threshold can be set as needed, and can be 10%, 15%, 20%, or other thresholds, and at the same time, this first occupancy rate threshold can be dynamically adjusted.

[0160] According to this embodiment, by allocating the target services to the corresponding operating systems in accordance with the service resource occupancy rate, it is possible to ensure immediate response to services with low service resource occupancy rates. Selectively, A method of allocating to the first operating system a service to be allocated among the services to be allocated in one group, the service having a service coupling degree with a service already allocated to the first operating system equal to or greater than a first coupling degree threshold; and a method of allocating to the second operating system, among the services to be allocated in one group, those services to be allocated that have a service coupling degree with the already allocated services of the second operating system equal to or greater than a second coupling degree threshold, so that the services to be allocated in one group can be allocated to the corresponding operating systems in the embedded system according to a dynamic resource allocation rule, but the present invention is not limited to these methods.

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

[0162] Alternatively, service coupling can be evaluated based on the relationship between the input and output of a service, and service coupling can be expressed by various coupling levels. If there is no relationship between the input and output of a service, the coupling level is low (or another coupling level indicating no relationship between the services). If the execution of one service depends on the output of another application (the service cannot start without this output as input), the coupling level between services is high. If the execution of one service uses the output of another application, but this output does not interfere with the normal execution of the service (it is sufficient for the service to obtain this output when executing the corresponding operation, and the corresponding operation is not a core operation), the coupling level between services is medium. Service coupling can also be expressed by a numerical value, or service coupling can be evaluated based on one or more coupling conditions (e.g., the associative relationship between input and output), and the numerical value corresponding to the satisfied coupling condition is determined as the service coupling value.

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

[0164] For example, in addition to generating a real-time service list and a non-real-time service list, the service management module is also responsible for service decoupling evaluation and management, i.e., finding out from all real-time services those services that can be handed over to the real-time operating system to run independently, and the hardware resource dynamic allocation module can easily reallocate processor resources, and for services that cannot be handed over to the real-time operating system to run independently, if they have a high degree of service coupling with non-real-time services, they can be allocated to the non-real-time operating system.

[0165] Here, some services have real-time requirements, but interact frequently with other non-real-time services in the system (i.e., the degree of service coupling is high). In this case, to improve the overall efficiency of data interaction, such services are assigned to a non-real-time operating system. If there is another type of real-time service that is relatively independent, it can be assigned to a real-time operating system; this process is called a "decoupling" operation. There is no single criterion for determining whether a service is independent; it can be the degree of relative familiarity between the services or an indicator of interest to other users.

[0166] The reallocation policy is open. One possible policy is to allocate processor cores based on the proportion of the number of services allocated to the real-time operating system and the non-real-time operating system by the service management module when the system is first run, and then adjust the resource allocation based on the core resource occupancy rate of each in the dual system. From this perspective, the reallocation process and the core preemption and release process are mutually cooperative processes.

[0167] According to this embodiment, by allocating the target services to the corresponding operating systems in accordance with the service coupling degree, it is possible to ensure the accuracy of service processing for a plurality of services with a relatively high service coupling degree. Selectively, The services to be assigned in one group, which include sensitive information, can be assigned to a target operating system, in which the target operating system is one of a first operating system and a second operating system, which has a low interaction frequency with the user, according to a resource dynamic allocation rule, by utilizing a method, but not limited to these methods, to assign the services to be assigned in one group to a corresponding operating system in an embedded system.

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

[0169] For example, the service processing module can further implement hardcore security isolation for system services, classifying important and sensitive services (those not desired to be disclosed to users) as real-time services, and finally offloading these services from the non-real-time operating system to the real-time operating system to fulfill the security function. Here, when the different services classified by the service processing module are implemented in software, they can be arranged in the form of a structure. By designing a security space between heterogeneous operating systems, sensitive services can be offloaded from the non-real-time operating system to the real-time operating system to achieve the hardcore security goal. Here, sensitive services refer to security-related services, such as services related to user privacy, such as user passwords and identity information.

[0170] Here, the hard core level means that services are separated at the processor core level, i.e., sensitive services are assigned to the real-time operating system (the cores occupied by the real-time operating system are different from those of non-real-time operating systems, so they belong to the core-level separation). Because the real-time operating system has less frequent and less intense interaction with users than non-real-time operating systems, it is difficult for users to "detect" sensitive data generated by services running on it. For higher-level applications, services such as user identity authentication management and secure encryption belong to the above-mentioned important and sensitive services. The service management module forcibly classifies these services as real-time services, and then, when dynamically allocating hardware resources, these services can be run on the real-time operating system, thereby achieving the effect of secure separation.

[0171] According to this embodiment, by assigning a service that contains sensitive information to an operating system that has low frequency of user interaction, hardcore level security isolation can be achieved for system services, thereby improving the safety of service execution. Alternatively, a method can be adopted in which, based on the allocation results of the services to be allocated to one group, the resource utilization status of the processing resources of the first operating system and the resource utilization status of the processing resources of the second operating system are linked to generate a resource mapping table of the services to be allocated to one group and the processing resources of the processor, thereby determining the resource allocation results corresponding to the services to be allocated to one group, but this method is not limited to this.

[0172] In this embodiment, the allocation result of the services to be assigned in a group is used to indicate the correspondence between the services to be assigned and the operating systems, and the services to be executed assigned to an operating system are generally executed using the processing resources of this operating system, while if the amount of services assigned to an operating system is too large and there are currently unallocated processing resources, the unallocated processing resources may be allocated to the services to be assigned to the operating system. Therefore, based on the allocation result of the services to be assigned in a group, the resource utilization status of the processing resources of the first operating system and the resource utilization status of the processing resources of the second operating system can be combined to generate a resource mapping table of the services to be assigned in a group and the processing resources of the processor, which is used to indicate the processing resources allocated to each service to be assigned.

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

[0174] For example, the dynamic resource allocation module dynamically adjusts processor resources based on the output result of the service management module, forms a resource mapping table between different services and actual hardware resources, optimizes the deployment structure of different hardware resources in the heterogeneous operating system, and achieves the purpose of improving the utilization rate of the hardware resources of the entire system. The dynamic resource allocation process is managed and configured by software in the second operating system. Taking an eight-core processor (core 1 to core 8) as an example, the processor cores scheduled to the first operating system include core 1, and the processor cores already scheduled to the second operating system include core 2, core 3, and core 4. There are six services to be assigned, with real-time services being service 1 and service 2, and non-real-time services being service 3 to service 6. Processor cores corresponding to the six services are assigned, with core 1 assigned to service 1, core 5 assigned to service 2, core 2 assigned to service 3, core 3 assigned to service 4, core 4 assigned to service 5, and core 6 assigned to service 6.

[0175] According to this embodiment, the processing resource usage status of different operating systems is linked based on the correspondence between services and operating systems, and processing resources can be dynamically allocated, thereby ensuring rationality in the allocation of processing resources. Alternatively, if it is determined based on the resource allocation result that an unallocated processing resource among the processor's processing resources has a corresponding service to be allocated, a method of allocating the unallocated processing resource to an operating system to which the service to be allocated corresponding to the unallocated processing resource has been allocated can be adopted, and the processor's processing resources can 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, but is not limited to these methods.

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

[0177] Optionally, the resource adaptive scheduling module can complete an actual scheduling operation of the processor's processing resources based on the result of the dynamic allocation of hardware resources, such as scheduling some of the processor cores to run services assigned to the first operating system (e.g., scheduling M cores in core group 1), and scheduling the remaining processor cores to run services assigned to the second operating system (e.g., scheduling N cores in core group 2).

[0178] Taking the aforementioned 8-core processor as an example, based on the service allocation result and resource allocation result, unallocated core 4 may be allocated to the first operating system, and unallocated cores 5 and 6 may be allocated to the Linux system. The entire scheduling process may be mastered by the second operating system. According to this embodiment, based on the resource allocation result, the unallocated processor resources are scheduled to the corresponding operating systems, thereby improving the utilization rate of the processor resources.

[0179] In one exemplary embodiment, in one alternative embodiment, there is provided a method for inter-core communication, the method including the steps of: Step 1: A first operating system sends target data (which may be service data) to a target virtual channel (which may be storage space) in the memory of a processor.

[0180] Optionally, the target data is data to be sent, the target virtual channel is an idle storage space in memory, and sending the target data to the target virtual channel in the processor's memory by the first operating system means writing the data to be sent to the target virtual channel by the CPU core of the first operating system.

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

[0182] Step 3: The second operating system responds to the interrupt notification message and acquires target data from the target virtual channel in the memory. Optionally, the CPU core of the second operating system responds to the interrupt notification message, analyzes the address of the target virtual channel from the interrupt notification message, and locates the target virtual channel in the memory based on the analyzed address to acquire the target data from the target virtual channel, thereby realizing data interaction between the first operating system and the second operating system. Through the above steps, when multiple operating systems running on a processor need to transmit data to each other, the first operating system that sends the data will send the target data to a target virtual channel in the processor's memory and send an interrupt notification message to the second operating system. The second operating system that receives the data will respond to the interrupt notification message and obtain the target data from the target virtual channel, thereby solving the problems of resource waste and high dependency on operating systems in the inter-core communication process and achieving the effects of reducing resource waste and dependency on operating systems in the inter-core communication process.

[0183] In one exemplary embodiment, the memory includes a data storage area and a metadata storage area, the data storage area is partitioned into a plurality of storage units, each storage unit is used to store service data, and the metadata storage area is used to store the size and occupancy status of each storage unit of the data storage area. Optionally, the target virtual channel may be composed of one or more storage units of the data storage area, and the metadata storage area may be divided into storage sheets equal to the number of storage units, each storage sheet being used to record the size and occupied status of one storage unit, the size of the storage unit may be represented by the start address and end address of the storage unit, or may be represented by the start address and length of the storage unit, and the occupied status includes an occupied state and an unoccupied state and may be represented by the numerical value of an idle mark.

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

[0185] In addition, to ensure that the target data can be written continuously to the memory, the target virtual channel to be written to must be idle and have a storage space that is equal to or greater than the length of the target data. Since the memory is divided into a metadata storage area and a data storage area, the occupancy status of each storage unit recorded in the metadata storage area can be read to find a storage unit that is idle and can meet the data storage demand. For example, if the size of each storage unit is the same and the length of the target data is greater than the length of one storage space, the number of required storage units is determined based on the length of the target data, and then a number of idle, consecutive storage units that meet the data storage demand are found to form a target virtual channel.

[0186] Alternatively, for example, each storage unit may have the same size, and the data storage area may have previously combined storage units to obtain multiple virtual channels of different sizes, each virtual channel being composed of a combination of one or more storage units. The occupancy status of each virtual channel recorded in the metadata storage area may be read to find a virtual channel that is idle and whose length is greater than the length of the target data, i.e., the target virtual channel. When the system software requests memory space sharing, it determines whether the requested data length is greater than the maximum length of data that can be stored by the virtual channel. If it is greater than the maximum length of data that can be stored by the virtual channel, the system software may transmit the data that needs to be transmitted in multiple batches, ensuring that the length of the data transmitted each time is less than the maximum length of data that can be stored by the virtual channel, thereby ensuring smooth communication.

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

[0188] That is, after the second operating system extracts the target data from the storage unit corresponding to the target virtual channel, the state of the storage unit corresponding to the target virtual channel is set to an idle state to prevent other systems or tasks from affecting the use of the target virtual channel. In one exemplary embodiment, sending target data to a target virtual channel in the memory of the processor by the first operating system includes a driver layer of the first operating system receiving the target data, determining an idle virtual channel in the memory, obtaining the target virtual channel, setting the state of the target virtual channel to an occupied state, and storing the target data in the target virtual channel.

[0189] Optionally, both the real-time operating system and the non-real-time operating system have a driver layer, and after the driver layer receives target data to be sent, it calls an interface to search for the target virtual channel in memory, and in the process of writing data, in order to prevent other systems from applying to use the target virtual channel, after finding the target virtual channel, it sets the state of the target virtual channel to an occupied state, and then writes the target data to the target virtual channel.

[0190] In one exemplary embodiment, when the first operating system includes an application layer, a human-machine interaction interface is installed in the application layer, and before the driver layer of the first operating system determines the virtual channel in an idle state in the memory, the application layer of the first operating system may receive data to be sent input by a user through the human-machine interaction interface, adopt a preset format to package the data to be sent, obtain the target data, and call a data write function to transmit the target data to the driver layer through the preset communication interface, where the preset communication interface is installed in the driver layer.

[0191] Optionally, the application layer may fill in the data that needs to be sent according to a preset format, obtain the target data, and create a device file ipidev in the / dev / system root; when the application layer needs to read or write data from the driver layer, it may first use the system-owned open function to open the device file / dev / ipidev, and then use the system-owned write function to send the target data from the application layer to the driver layer; the driver layer may further store the data in a target virtual channel in shared memory, and then trigger an interrupt to notify the second operating system to read the data.

[0192] In one exemplary embodiment, the second operating system responding to the interrupt notification message to obtain target data from a target virtual channel in memory includes the second operating system triggering an interrupt handling function based on the interrupt notification message, determining the target virtual channel from memory by the interrupt handling function, and obtaining the target data from the target virtual channel.

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

[0194] In one exemplary embodiment, when the second operating system includes an application layer, a function identifier is stored in the memory, the function identifier indicating a target function; determining a target virtual channel from the memory by an interrupt handling function and obtaining target data from the target virtual channel includes determining a function identifier and a target virtual channel from the memory by an interrupt handling function and sending address information of the target virtual channel to a target application program matching the function flag, where the target application program is a target application program in the application layer; and the target application program calling a data read function and transmitting the address information to a driver layer through a preset communication interface, where the driver layer obtains the target data from the target virtual channel and transmits the target data to the target application layer program, where the preset communication interface is installed in the driver layer, and the target application program processes the target data based on the processing function matching the function identifier to perform the target function.

[0195] Optionally, after the second application system receives the interrupt notification message, the application layer calls a corresponding interrupt handling function to find the target virtual channel in memory, obtain the address information of the target virtual channel, and create a device file ipidev in the / dev / system directory; when the application layer needs to read or write data from the driver layer, it can first use the system-owned open function to open the device file / dev / ipidev, and then use the system-owned read function to read the target data in the target virtual channel; that is, the driver layer finds the corresponding target data in the shared memory based on the address information of the target virtual channel, and returns the target data and the length of the target data to the application layer; and in one exemplary embodiment, sets the state of the target virtual channel to idle.

[0196] In addition, different application programs in the application layer may realize different functions using target data. A function identifier is stored in the memory, and the function identifier indicates the target function that the application program realizes using the target data. Optionally, the function identifier may be Net, Cmd. When the system is initialized, Net, Cmd and the application program PID are registered in the driver. The driver layer can find the PID of the application program based on the received NetFn and Cmd, and send data to the corresponding application program based on the PID.

[0197] For example, when NetFn=1 and Cmd=1, it represents that the first operating system and the second operating system send "hello word" to each other. When the system starts, an array is initialized, which has a total of three columns, the first column is NetFn, the second column is Cmd, and the processing function corresponding to NetFn and Cmd in the third column is xxCmdHandler. For example, when the second operating system receives a message sent from the first operating system, it obtains NetFn and Cmd from the message, and if it determines that NetFn=1 and Cmd=1, it executes the processing function HelloCmdHandler corresponding to "hello word" to complete the corresponding function.

[0198] In one exemplary embodiment, the data storage area includes a plurality of memory channels, each memory channel being composed of one or more storage units; a plurality of records are stored in the metadata storage area, each record being used to record metadata of one memory channel, the metadata of each memory channel including at least the channel ID of the memory channel, the size of the memory channel, and the occupied state of the memory channel; reading the records in the metadata storage area by a first operating system and determining, based on the read records, at least one storage unit in the data storage area that is in an idle state and whose total space is equal to or greater than the length of the target data; obtaining a target virtual channel includes traversing the records stored in the metadata storage area to determine whether there is a first target record indicating that the memory channel is in an idle state and that the size of the memory channel is equal to or greater than 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.

[0199] The data storage area may be divided into n virtual memory channels, each of which may have a different size. That is, the sizes of the n virtual memory channels are 20*m, 21*m, 22*m, 23*m... 2n-1*m, respectively, where m is the size of one storage unit. The following structure is used as metadata to manage the memory channels:

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

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

[0202] In one exemplary embodiment, when the first operating system determines a target virtual channel, it uses the interface GetEmptyChannel to search all memory channels based on the size of the target data to be sent for a virtual channel that meets two conditions: the idle flag Flag in the channel structure IpiHeader is not equal to 0xA5A5A5A5 (i.e., the channel is in an idle state), and the channel size ChannelSize in the channel structure IpiHeader is equal to or greater than the size of the target data (i.e., the memory size can meet the storage demand of the target data). After finding a target virtual channel that meets the above conditions, it sets the state of this channel to not empty, i.e., sets the idle flag Flag in the channel structure IpiHeader to 0xA5A5A5A5, and then copies the target data to the target virtual channel.

[0203] In one exemplary embodiment, when the memory channel is occupied, the metadata of the memory channel further includes an ID of an originating CPU core of the target data and an ID of a destination CPU core of the target data, and reading a record in the metadata storage area by the second operating system and determining a target virtual channel based on the read record includes traversing the records stored in the metadata storage area to determine whether a second target record exists, where the second target record indicates that the memory channel is in an occupied state, the ID of the destination CPU core is the ID of a CPU core of the second operating system, and the ID of the originating CPU core is not the ID of a CPU core of the second operating system, and if the second target record exists, determining a memory channel indicated by the channel ID recorded in the second target record as the target virtual channel.

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

[0205] In addition, when the idle flag is represented by one bit, 0 indicates that the channel is empty and 1 indicates that the channel is not empty. If the flag is originally 0 and mutates to 1, the system will read the flag and think that the channel is not empty, causing a communication error. In contrast, in this embodiment, the idle flag is set to a multi-bit special character, for example, 0xA5A5A5A5, and the probability of multiple bits mutating to a special character at the same time is significantly smaller than the probability of a single bit mutation. This prevents mutations of storage medium bits from affecting the value of the flag, improving communication security.

[0206] In one exemplary embodiment, a state mapping table is stored in the metadata storage area, the state mapping table has a plurality of records, each record is used to record the occupied state of one storage unit, reading the records in the metadata storage area by the first operating system, and determining at least one storage unit in the data storage area that is in an idle state based on the read records and whose total space is equal to or greater than the length of the target data, and obtaining a target virtual channel includes determining a predetermined number of storage units that the target data is to occupy, sequentially scanning each record from an initial position of the state mapping table, and when the predetermined number of consecutive target records are scanned, determining consecutive storage units indicated by the predetermined number of target records, where the target records represent that the storage units are in an idle state, and determining the consecutive storage units as the target virtual channel.

[0207] In addition, when transmitting service data through the operating system, in order to easily store and retrieve data, it is necessary to occupy consecutive storage units in memory. Therefore, the number of storage units in the memory application command must first be determined. Since the memory space of each storage unit is the same, the predetermined number of consecutive storage units required can be calculated based on the required memory space size, which is called numb.

[0208] Optionally, the first operating system traverses the records from an index position in the state mapping table, where the index position may be the starting position of the state mapping table, and sequentially searches through each record in the state mapping table from the starting position of the state mapping table to determine whether there is a record that consecutively records that the number of idle memory pages is equal to or greater than numb. If there is a record that satisfies the above condition, determine consecutive storage units in the processor based on the correspondence between the record and the memory page, and determine this consecutive storage unit as a target virtual channel, and write data to the target virtual channel.

[0209] In one exemplary embodiment, the interrupt notification message includes a starting address and a predetermined number of consecutive storage units, and reading the record in the metadata storage area by the second operating system and determining a target virtual channel based on the read record includes scanning each record in order from an initial position of the state mapping table, and when it is scanned that the starting address of the consecutive storage units is recorded, determining the storage unit indicated by the scanned address and the consecutive storage units equal to the predetermined number minus one as the target virtual channel.

[0210] Optionally, the consecutive storage units refer to consecutive storage units whose number is equal to numb, and each record in the state mapping table further records the starting address of the corresponding storage unit. When the second operating system scans the record of the starting address of consecutive storage units whose number is equal to numb in the mapping table, it represents that the starting address of the target virtual channel has been scanned. The storage unit indicated by the starting address and numb-1 consecutive storage units after this storage unit constitute the target virtual channel, and the second operating system completes data interaction with the first operating system by obtaining data from the target virtual channel.

[0211] In one exemplary embodiment, a counter records the scanned target records, and in the process of sequentially scanning each record from the initial position of the state mapping table according to the number of storage units, if a target record is currently scanned, the counter is controlled to be incremented by 1, and if a non-target record is currently scanned, the counter is controlled to be cleared.

[0212] Optionally, the magnitude relationship between the value of the counter and the number of required storage units is used to determine whether a predetermined number of consecutive target records exist, i.e., whether a predetermined number of consecutive storage units exist. Optionally, the count value of the counter is set as cntr. If a scanned storage unit is empty, cntr is incremented by 1. If the scanned storage unit is not empty, the accumulated number of consecutive idle storage units cntr is cleared. Starting from the address one address after this storage unit, consecutive idle storage units are searched for. If cntr is equal to numb, it indicates that consecutive idle storage units that meet the memory demand have been found. If cntr is not equal to or greater than numb after scanning the entire state mapping table, it indicates that the dynamic memory application has failed this time and that the predetermined number of consecutive storage units do not exist.

[0213] In one exemplary embodiment, before reading the record in the metadata storage area by the first operating system and determining, based on the read record, 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, and obtaining the target virtual channel, the method further includes sending a memory application command by the first operating system and performing a lock operation on the processor's memory, where the memory application command is used to apply for use of the processor's memory, and if the lock on the memory is successful, reading the record in the state mapping table.

[0214] Alternatively, the memory application command is a command issued by an operating system running on a processor to apply for use of the processor's memory. Furthermore, in order to prevent application conflicts when multiple operating systems simultaneously apply to use the processor's memory, when the operating system sends a memory application command, it may first perform a lock operation on the processor's memory, and apply to use the memory after the lock is successful. A lock operation refers to an exclusive operation for applying for memory. If the lock is not released after the operating system has successfully locked it, other servers do not have the right to apply to use the processor's memory.

[0215] In one exemplary embodiment, performing a lock operation on the processor's memory includes determining whether the memory is currently in a locked state, where a locked state indicates that the memory is in a state where it is offered for use; performing the lock operation on the memory if the memory is not currently in a locked state; and determining that the lock on the memory has failed if the memory is currently in a locked state, and re-applying for a lock on the processor's memory after a preset length of time until the lock on the memory is successful or the number of lock applications is greater than a preset number.

[0216] Before the processor is run, it is necessary to initialize the metadata storage area and the data storage area in the processor, and optionally initialize the records stored in the state mapping table in the metadata storage area and initialize the memory management information. Before performing the memory application operation, the memory management information is arranged as follows: typedef struct { uint32_t MemReady; uint32_t MemLock; }MallocMemInfo_T;

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

[0218] Alternatively, if the variable MemLock is read as 0, it indicates that there is no system or task currently requesting memory, i.e., the memory is not currently locked. If the variable MemLock is read as 0xA5A5A5A5, it indicates that there is a system or task requesting memory, and that it will need to request again after the current request is completed, and the current request for locking has failed. In one exemplary embodiment, if there is a situation where the lock fails when performing a lock operation on memory, the lock on the memory is reapplied for after waiting a preset length of time until the lock is successful, for example, the preset length of time may be 100 microseconds.

[0219] In one exemplary embodiment, if a lock application fails and the number of repeated applications exceeds a preset number, it indicates that memory is unavailable for allocation in the processor for the current length of time, and the application operation is stopped. For example, the preset number may be three times, and if the number of lock applications is greater than three, a message indicating that memory is currently unavailable may be returned to the operating system that sent the application.

[0220] Optionally, after there is a target virtual channel in the processor's memory space that can be used by the first operating system, the first operating system stores the target data that needs to be transmitted in the corresponding target virtual channel, and in one exemplary embodiment, updates the occupation status of the processor's memory space based on the data writing status of the first operating system, i.e., changes the target continuous memory space from an unoccupied state to an occupied state, and releases the lock on the memory so that other systems or tasks can apply for the memory.

[0221] In one exemplary embodiment, the method further includes releasing the lock on the memory if a consecutive, preset number of target records have not been scanned. Optionally, if a predetermined number of consecutive idle storage units are not detected after scanning the records in the state mapping table, the processor's memory does not have enough free memory pages for the first operating system to use, and the current dynamic memory application fails, and the lock on the memory is released.

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

[0223] Alternatively, a soft interrupt is an interrupt generated by software, and the software may send the interrupt to the CPU core that runs the software itself or to another CPU core. The preset register may be the GICD_SGIR register, and software may write an SGI (Software Generated Interrupts) interrupt number and a destination CPU ID to the GICD_SGIR register to generate a software interrupt, and the SGI interrupt number is a soft interrupt number reserved for inter-core communication. In a multi-core heterogeneous operating system, in order to maximize compatibility with current resource allocation methods, numbers 8 to 15 (a total of 8 interrupts) are used to represent the inter-core interrupt vector table. If the first operating system is an RTOS operating system and the second operating system is a Linux operating system, one possible allocation scheme for the vector table is shown in Table 1.

[0224] [Table 1]

[0225] Alternatively, a hardware interrupt refers to an interrupt generated by a hardware device, and may be a private external device interrupt or a shared external device interrupt. A hard interrupt is an interrupt generated by hardware external to the CPU and is random, while a soft interrupt is an interrupt generated by software running on the CPU by executing an interrupt command and is preset. This embodiment does not limit the method of generating an interrupt notification message.

[0226] In one alternative embodiment, a method for sharing memory is provided, the method comprising the steps of: Step 1: receiving a memory application command and performing a lock operation on the memory of a processor, where the memory application command is used to apply to use the memory of the processor.

[0227] Alternatively, the memory request command is a command issued by an operating system running on a processor to request use of the processor's memory, and may be sent by a first operating system. To prevent conflicts in requests when multiple operating systems simultaneously request use of the processor's memory, when an operating system sends a memory request command, it may first perform a lock operation on the processor's memory and request use of the memory after the lock is successful. The lock operation refers to an exclusive operation of memory request. If the lock is not released after the current operating system successfully locks the memory, other servers will not have the right to request use of the processor's memory.

[0228] In a method for sharing memory according to an embodiment of the present application, before performing a lock operation on the memory of a processor, the method further includes determining whether the memory is currently in a locked state, where the locked state indicates that the memory is in a state offered for use, and performing a lock operation on the memory if the memory is not currently in a locked state.

[0229] Alternatively, if multiple systems or multiple tasks simultaneously request to use memory, a conflict of requests will occur, and therefore the processor's memory can only be locked by one system or task within the same time period. Therefore, if the operating system detects that the memory is not currently in a locked state, it can perform a lock operation on the memory.

[0230] Alternatively, determine whether the memory is in a locked state by determining whether a preset variable stored in the memory is a preset value. If the preset variable is not a preset parameter, it indicates that the memory is not in a locked state, there are no other systems or tasks requesting memory space, and the locking is successful; otherwise, if the preset variable is a preset parameter, the memory is in a locked state at the current time, there are systems or tasks requesting memory space other than this operating system, and the locking fails.

[0231] This method of sharing memory further includes, after determining whether the memory is currently in a state to be locked, determining that an attempt to lock the memory has failed if the memory is currently in a state to be locked, and, if an attempt to lock the memory has failed, reapplying for a lock on the processor's memory after a preset length of time until the memory is successfully locked or the number of attempts to apply for the lock exceeds a preset number. Alternatively, if a lock operation on the memory fails, the lock on the memory is reapplied for after waiting a preset time period until the lock is successful, for example, the preset time period may be 100 microseconds.

[0232] In one exemplary embodiment, if a lock application fails and the number of repeated applications exceeds a preset number, it indicates that memory is unavailable for allocation in the processor for the current length of time, and the application operation is stopped. For example, the preset number may be three times, and if the number of lock applications is greater than three, a message indicating that memory is currently unavailable may be returned to the operating system that sent the application. Step 2: If the memory is successfully locked, read the occupied state of the memory, and based on the read occupied state of the memory, determine whether there is an available target memory space in the memory, where the size of the target memory space is equal to or greater than the size of the memory applied for by the memory application command.

[0233] After the lock application is successful, the operating system applies for memory in the processor, and optionally, based on the memory application command issued by the operating system, scans the information for recording the occupied state of the memory to determine whether the target memory space exists, that is, determines whether the processor has a memory space that is unoccupied and contiguous and can meet the memory usage demand, where meeting the memory usage demand means that the size of the memory space is equal to or larger than the memory size applied by the operating system. In one exemplary embodiment, it is determined whether the size of the unoccupied and contiguous memory space is equal to or larger than the memory size applied by the operating system, and obtains a determination result.

[0234] In addition, when applying for memory, non-contiguous memory space can be used, and a pointer can be added after each non-minimum memory block to point to the minimum memory block acquired by the next application. At the same time, when reading or writing data, the memory address and pointer can be used to read or write data across data blocks. This embodiment does not limit the format of the target memory space.

[0235] Step 3: If the target memory space exists in the memory, the address information of the target memory space is fed back to the sender of the memory request command, updating the memory's occupied status and releasing the lock on the memory. Here, the sender refers to the operating system (e.g., the first operating system) that sends the memory request command. Note that when the operating systems communicate between cores, they use shared memory to send and receive data. In the process of sending and receiving data, they need to determine the address information of the memory space that has already been requested in order to access the data according to the address returned by the requested memory.

[0236] Optionally, after the processor finds that there is a target memory space available for the operating system in its memory space (which may be indicated by the aforementioned determination result), it sends address information of this target contiguous space to the operating system, and the operating system stores the data to be transmitted in the corresponding memory space based on the address information.

[0237] In one exemplary embodiment, based on the data writing status by the operating system, the occupation status of the processor's memory space is updated, i.e., the target memory space is changed from an unoccupied state to an occupied state, and the lock operation before dynamically applying for the memory is released, so that other operating systems can apply to use the processor's memory space.

[0238] The above steps solve the problems of low utilization efficiency, poor flexibility, and excessive dependency on the operating system of the shared memory between multiple cores, thereby achieving the effects of improving the flexibility and utilization rate of the shared memory and reducing dependency on the operating system. In this method of sharing memory, the memory includes a metadata storage area in which a state mapping table for storing the occupied state of the data storage area is stored, and a data storage area for storing service data, and 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 includes reading a record in the state mapping table from the metadata storage area and determining whether there is a target memory space in the data storage area based on the record in the state mapping table.

[0239] The occupied state of the memory is searched for by searching for records in a state mapping table, and optionally a metadata storage area stored in the processor is obtained, and the state mapping table in the metadata storage area is identified, and the occupied state of the data storage area is read by traversing the records in the state mapping table, and it is determined whether there is a contiguous, idle memory space in the data storage area that meets the memory usage demand.

[0240] In a method for sharing memory according to an embodiment of the present application, the data storage area is composed of a plurality of memory pages, and the state mapping table includes a plurality of records, each of which is used to record the occupied state of one memory page; reading the records in the state mapping table from the metadata storage area and determining whether the target memory space exists in the data storage area based on the records in the read state mapping table includes: determining a predetermined number of memory pages to be applied for by the memory application command; scanning each record in the state mapping table in order from an initial position; and determining that the target memory space exists in the memory when scanning the predetermined number of consecutive target records, where the target record indicates that the memory page is in an idle state.

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

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

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

[0244] In one exemplary embodiment, after obtaining a state mapping table in a metadata storage area of ​​a processor, traverse the memory page records from an index position in the state mapping table, where the index position may be the start position of the state mapping table, and sequentially search each memory page record in the state mapping table from the start position of the state mapping table to determine whether there is a memory page record that consecutively records that the number of idle memory pages is equal to or greater than numb; if there is a memory page record that satisfies the above condition, determine that the target memory space exists in the processor based on the correspondence between the memory page record and the memory page.

[0245] In the method for sharing memory according to an embodiment of the present application, after scanning each record in order from the initial position of the state mapping table, the method further includes scanning all records in the state mapping table, and determining that there is no target memory space in the memory if there are no consecutive, predetermined number of target records.

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

[0247] In the memory sharing method according to the embodiment of the present application, the number of scanned target records is recorded by a counter, and in the process of scanning each record in turn from the initial position of the state mapping table, if a target record is currently scanned, the counter is controlled to be incremented by 1, and if a non-target record is currently scanned, the counter is controlled to be cleared, where the non-target record represents that the memory page is in an occupied state.

[0248] Optionally, determine whether a predetermined number of consecutive target records exist, i.e., whether the target memory space exists, based on the magnitude relationship between the value of the counter and the number of required memory pages; optionally, set the count of the counter as cntr; if a scanned memory page is empty, add 1 to cntr; if the scanned memory page is not empty, clear the accumulated number of consecutive idle memory pages cntr; continue to search for consecutive idle memory pages from one address after this memory page; if cntr is equal to numb, it indicates that consecutive idle memory pages that meet the memory demand have been found; if cntr is less than numb during the process of scanning the entire state mapping table, it indicates that the dynamic memory application this time has failed and the target memory space does not exist.

[0249] In the memory sharing method according to an embodiment of the present application, when the initial position is the last position in the state mapping table, feeding back address information of the target memory space to the sending end of the memory application command includes determining the last scanned target record in a predetermined number of consecutive target records, and feeding back the starting address of the memory page indicated by the last scanned target record to the sending end.

[0250] Optionally, when scanning the state mapping table, the scanning method can be selected to scan from the first position of the state mapping table or scan from the last position of the state mapping table. When the scanning method is to scan from the last position of the state mapping table, if the value cntr displayed on the counter is equal to or greater than a preset number numb, the start address of the memory page corresponding to the last scanned memory page record is set as the state of these memory pages in the memory page record as non-empty, and the start address is set as the start address of all consecutive memory pages of this memory application command.

[0251] In one exemplary embodiment, this address is fed back to the operating system which issues a memory application command, and the operating system performs a data write operation to the memory based on the address information. In a memory sharing method according to an embodiment of the present application, the initial location is the first location in the state mapping table, and feeding back address information of the target memory space to the sending end of the memory application command includes determining the first scanned target record in a predetermined number of consecutive target records, and feeding back the starting address of the memory page indicated by the first scanned target record to the sending end.

[0252] Alternatively, if the scanning method is to scan from the first position of the state mapping table, and the value cntr displayed on the counter is equal to or greater than the preset number numb, the address of the first scanned memory page record is used as the starting address and sent to the operating system to issue a memory application command, and the operating system performs a data write operation on the memory based on the address information.

[0253] In the memory sharing method according to the embodiment of the present application, in the process of scanning each record in order from the initial position of the state mapping table, the first target record in the scanned consecutive target records is stored according to a preset variable. Optionally, the preset variable refers to a variable for storing address information of an initial position in the state mapping table, and is set as offset. Every time one free, consecutive memory page is scanned, the counter value cntr is incremented by 1. When the counter value cntr is equal to or greater than the preset number numb, the address information currently stored in offset is set as the address of the first target record.

[0254] In the method for sharing a memory according to an embodiment of the present application, 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 if it is determined that there is no free target memory space in the memory.

[0255] Optionally, scan the memory page records in the state mapping table, and if it is found that the record does not contain a predetermined number of contiguous free memory pages, i.e., does not contain the target memory space, it indicates that the processor memory does not have enough free memory pages for the operating system to use, and the dynamic memory request fails, and the memory lock is released.

[0256] In a method for sharing memory according to an embodiment of the present application, the memory includes a metadata storage area in which memory management information is stored and a data storage area for storing service data, and determining whether the memory is currently in a locked state includes reading the memory management information stored in the metadata storage area and determining whether the memory management information includes preset information, where the preset information indicates that the memory is in a locked state, determining that the memory is not currently in a locked state if the memory management information includes the preset information, and determining that the memory is currently in a locked state if the memory management information does not include the preset information.

[0257] When determining whether the processor's memory is in a locked state, it is necessary to make the determination using memory management information in the metadata storage area. Optionally, when the memory management information in the metadata storage area is obtained, it is determined whether the memory management information contains preset information, where the preset information 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 memory is currently in an unlocked state; otherwise, it indicates that the memory is in a locked state.

[0258] In a method of sharing memory according to an embodiment of the present application, the memory management information includes first field information and second field information, the first field information is used to describe whether the memory is in a locked state, and the second field information is used to describe whether the memory has been initialized, and before receiving a memory application command, the method further includes initializing the first field information and the second field information stored in the data storage area.

[0259] Before the embedded system is operated, it is necessary to perform initialization operations on the metadata storage area and data storage area in the processor, and optionally initialize the memory page records stored in the state mapping table in the metadata storage area and perform initialization operations on the memory management information. Optionally, the memory management information comprises first field information and second field information, the first field information representing whether it is locked, and the second field information representing whether it is initialized.

[0260] In the method for sharing memory according to an embodiment of the present application, updating the occupied state of memory changes the state of the memory page corresponding to the target memory space recorded in the state mapping table to the occupied state. Optionally, when the operating system needs to occupy the target memory space, by identifying the address information of multiple memory pages in the target memory space, update the memory page records in the status mapping table area of ​​the metadata storage area according to the correspondence between the memory pages and the memory page records, changing the unoccupied state to the occupied state.Furthermore, according to the data writing status of the operating system, update the occupation state of the processor's memory space, i.e., change the target memory space from the unoccupied state to the occupied state, and release the lock operation before dynamically applying the memory.

[0261] Optionally, in response to a storage operation of the first operating system, store target data in the target memory space and send address information of the contiguous memory space to the second operating system, receive an acquisition command 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.

[0262] Here, after successfully applying for memory, the first operating system stores the target data to be transferred in the applied target memory space, and sends the address information of the target memory space to the second operating system cooperating with the first operating system to notify the second operating system of data acquisition. Optionally, after receiving the address information of the target memory space, the second operating system issues a data acquisition command, and the embedded system receives this command and sends the target data stored in the target memory space to the second operating system.

[0263] Through the above steps, a memory application command is received from the first operating system, and a lock operation is performed on the processor's memory. The memory application command is used to apply for use of the processor's memory. If the memory lock is successful, the memory's occupied status is read, and based on the memory's occupied status, it is determined whether there is an available target memory space in the memory. If the size of the target memory space is equal to or greater than the memory size applied for by the memory application command and there is a target memory space in the memory, the address information of the target memory space is fed back to the sending end of the memory application command, the memory's occupied status is updated, and the memory is unlocked. In response to the storage operation of the first operating system, the target data is stored in the target memory space, and the address information of the contiguous memory space is sent to the second operating system. The second operating system sends an acquire command based on the address information, and the target data stored in the target memory space is sent to the second operating system. This solves the problems of low utilization efficiency, low flexibility, and excessive dependency on the operating system of shared memory between multiple cores, and achieves the effects of improving the flexibility and utilization efficiency of shared memory and reducing dependency on the operating system.

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

[0265] When inter-core communication uses shared memory to send and receive data, addresses returned by dynamically allocated memory are used. However, different systems may use different address systems. For example, the real-time operating system is the first operating system and the non-real-time operating system is the second operating system. If the real-time operating system directly accesses the shared memory using a physical address, while the non-real-time operating system cannot directly access the shared memory using a physical address, it must use a mapped virtual address. After the second operating system receives the address information of the target memory space, it converts the address information (offset) and maps it to a virtual address, and performs operations based on the virtual address. Optionally, the non-real-time operating system shares a memory virtual base address vBase (where the true physical address of the shared memory is 0x96000000), and the real-time operating system shares a memory physical base address pBase (i.e., 0x96000000).

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

[0267] In one exemplary embodiment, the memory includes a metadata storage area and a data storage area, and the metadata storage area and the data storage area are the same as those in the above-described embodiment and will not be further described here. Optionally, the method obtains a metadata storage area stored in the processor, identifies a state mapping table in the metadata storage area, traverses each memory page record from an index position in the state mapping table, sequentially searches each memory page record in the state mapping table, and determines whether there is a memory page record that consecutively records that the number of idle memory pages is equal to or greater than a predetermined number. If there is a memory page record that satisfies the above condition, determines that the target memory space exists in the processor based on the correspondence between the memory page record and the memory page, and determines that the target memory space exists in the processor based on the correspondence between the memory page record and the memory page.

[0268] This embodiment also provides a method for memory sharing, which includes the following steps: before issuing a memory application command by the operating system, a lock operation must be applied for and a determination must be made as to whether the lock is successful, in order to prevent application collisions caused by multiple operating systems simultaneously applying for processor memory space; if the determination result indicates that the lock for the dynamically applied memory is successful, the number of contiguous memory pages that need to be allocated is calculated based on the memory size in the issued memory application command, and this is set as nmemb; if the determination result indicates that the lock application fails, the application is issued again after waiting a certain time (which may be 100 microseconds) until the application is successful; and if the number of times the lock application fails is greater than a preset number (which may be three times), the memory application is logged out.

[0269] In one exemplary embodiment, after the lock application is successful, an initialization operation is performed on the metadata storage area of ​​the processor, and the last position of the state mapping table is set as offset. According to the required memory space size in the memory application command, the number of required contiguous memory pages is calculated, and the number of memory pages is set as nmemb. A counter for recording the number of memory pages is set as cmemb. Then, the state mapping table of the metadata storage area of ​​the processor is obtained, and the entire state mapping table is scanned from the offset position of the state mapping table. According to the correspondence between the memory page records stored in the state mapping table and the memory pages in the data storage area, Based on this, it searches for consecutive free memory pages. If the current memory page being scanned is occupied, it sets offset=offset-cmemb, and clears the consecutive free memory page data cmemb accumulated in the counter. It then continues to search for consecutive free memory pages from the new offset position. If the memory page being scanned is empty, i.e., in an idle state, it adds 1 to the counter value cmemb, and sets offset=offset-1 to continue determining the next memory page. When cmemb is equal to nmemb, i.e., the counter data is equal to the required memory space size, it indicates that it has scanned consecutive memory pages that meet the request.

[0270] In one exemplary embodiment, in the corresponding state mapping table, the memory page that meets the request is marked as an occupied state, and the starting address of the last found memory page is set as the starting address of all the dynamically applied consecutive memory pages, and the lock for dynamically applying the memory is released, and the memory has been successfully applied this time. In the process of scanning the entire state mapping table, if the offset value is less than 0, it means that there is no memory page available in the operating system that satisfies the request, and the dynamic memory application is unlocked, and the dynamic memory application fails this time.

[0271] Furthermore, if it is found that the space is not sufficient after dynamically applying for the space, the size may be dynamically adjusted, an updated memory application command may be issued again, and a lock operation may be performed on the memory. If the lock is successful, if the memory space that needs to be applied for by the updated memory application command becomes larger, it is determined whether the required memory space exists after the target contiguous memory that has already been applied for. If so, the application is successful. If the memory space that needs to be applied for by the updated memory application command becomes smaller, some memory space is released.

[0272] This embodiment divides multiple storage areas, and uses index locations to dynamically allocate space based on the size actually needed, and releases it after use. It is also possible to dynamically adjust the size if it is found that the space is insufficient after dynamically allocating it, thereby achieving the effect of improving the flexibility and utilization efficiency of shared memory. From the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be realized by adding a required general-purpose hardware platform to software, or of course, by hardware, and in many cases, the former is a more preferred embodiment. Based on this understanding, the technical solution of the present application may be essentially embodied in the form of a software product, or a part that contributes to the prior art may be embodied in the form of a software product, and this computer software product is stored in a storage medium (e.g., ROM / RAM, magnetic disk, optical disk) and includes multiple commands for causing a terminal device (which may be a mobile phone, computer, server, network device, etc.) to execute the methods of the embodiments of the present application.

[0273] According to another aspect of the embodiment of the present application, there is further provided an embedded system for implementing the above-mentioned embedded system startup control method. FIG. 10 is a schematic diagram of an optional embedded system according to the embodiment of the present application, and the embedded system includes: and at least two operating systems, wherein: The chip includes a processor 1002, a hardware controller 1004, a first bus 1006, and a second bus 1008, where: The bandwidth of the second bus 1008 is higher than the bandwidth of the first bus 1006, and the second bus 1008 is configured in a multi-master multi-slave mode, and the first bus 1006 is configured in a one-master multi-slave mode; At least two operating systems run on the processor 1002, where processing resources of the processor are dynamically allocated to the at least two operating systems, and the processing resources of the processor include processor cores; At least two operating systems communicate via a first bus 1006; At least two operating systems exercise control over the hardware controller via a second bus 1008 .

[0274] Here, the chip may be the BMC chip described above, the processor may be the multi-core processor described above, the hardware controller may be used to control an external device connected to a corresponding external interface, the first bus may be a bus, such as an APB, arranged in a one-master multi-slave mode and used by the processor to control between the hardware controllers, and the second bus may be a bus, such as an AHB, arranged in a multi-master multi-slave mode and used to communicate between multiple processor cores of the processor, and the bandwidth of the second bus is higher than the bandwidth of the first bus.

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

[0276] Optionally, at least two operating systems may be used to implement the startup control method for the embedded system, for example, a first operating system and a second operating system of the at least two operating systems may be used to implement the startup control method for the embedded system. Alternatively, the hardware controller may include one or more of the following controllers corresponding to chip external devices: I2C, USB (Universal Serial Bus), UART, ADC (Analog to Digital Converter), JTAG (Joint Test Action Group), RTC (Real Time Clock), GPIO (General Purpose Input / Output), WDT (Watch Dog Timer), Virtual UART, Super I / O, SGPIO (Serial General Purpose Input / Output), PWM (Pulse Width Modulation), FanTach (Fan Tach), Timer, PECI (Platform Environment Control Interface), and MailBox, but may also include other types of controllers, without being limited thereto. The external interface may include one or more, and may include, but is not limited to, an external interface corresponding to any one of the above controllers.

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

[0278] The cores and the controllers are connected to each other via a second bus, realizing interaction between the cores and the controllers. At the same time, the ARM cores are connected to the second bus (for example, they may be connected via an AXI bridge), and communication between the cores is realized by the second bus. In addition, the SOC submodule further realizes connection / communication between the second bus and the first bus (for example, by conversion using an APB bridge), thus providing a single physical path for the SOC submodule to access external devices on the first bus.

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

[0280] The BMC out-of-band sub-module mainly includes controllers for chip external devices such as PWM, GPIO, FanTech (fan tachometer), mailbox, etc. These controllers can realize out-of-band management functions such as PECI communication with the BMC (e.g., PECI is simulated using GPIO), fan cooperative control, etc. As can be seen from Figure 11, the BMC out-of-band sub-module may interact with the SOC sub-module via a second bus, but is not limited to this.

[0281] The BMC chip realizes interconnection between on-chip ARM cores, storage units, and controller hardware resources via the first and second buses. Dynamic equalization scheduling of processor resources mainly relates to the ARM core resource scheduling of the BMC chip, and inter-core communication refers to communication between ARM cores. For example, a Linux system preempts an RTOS system core. The Linux system first sends an inter-core interrupt (interrupt number 9) to core 1 via the on-chip second bus on one of cores 2 through N. If the RTOS system is idle and allows preemption, core 1 returns an inter-core interrupt (interrupt number 10) via the second bus, releasing the external device controller resource (e.g., PWM / PECI) currently mapped by core 1. The Linux system receives inter-core interrupt 10 and issues a preemption request, adding core 1 to the Linux SMP scheduling and taking control of the PWM / PECI external device, which can then be controlled via the first bus.

[0282] According to one aspect, the at least two operating systems include a first operating system and a second operating system, wherein the chip realizes communication between the first operating system and the second operating system by loading a communication value onto a second bus, and the second bus sends a communication signal including the communication value to a communication register corresponding to the second operating system, wherein the communication value is used to indicate the content of communication between the first operating system and the second operating system.

[0283] Meanwhile, the chip loads the control value onto the first bus, and the first bus transmits a control signal including the control value to a register corresponding to the hardware controller, thereby realizing the operating system's control over the hardware controller, where the control value is used to indicate the content of the operating system's control over the hardware controller.

[0284] The operating system controls the hardware controllers by accessing the registers of each hardware controller (e.g., by performing read and write operations). The operating system's access to the registers of the hardware controllers may be, but is not limited to, by reading and writing the addresses of the registers of each hardware controller. The addresses of these registers may be, but are not limited to, unique and deterministic when the chip is designed. For example, the operating system can realize a specific function (e.g., a communication function between the operating systems or a control function of the operating system for the hardware controller) by writing a specific value (e.g., the communication value or control value) to a specific address (e.g., the communication register or a register corresponding to the hardware controller). That is, different functions correspond to different control values, and a correspondence between the functions of the hardware controllers and the control values ​​is maintained in the chip. For example, a control value of 00 indicates that the air conditioner is to be accelerated by one step, and a control value of 01 indicates that the air conditioner is to be decelerated by one step.

[0285] Interactions such as communication and control between each operating system and between the operating system and the hardware controller may be performed via a bus, but are not limited to this. The read / write operations of the operating systems to the registers of each hardware controller are ultimately converted into control signals for the hardware controller of the first bus (or the second bus). These conversion operations and the control process for the hardware controller of the first bus (or the second bus) may be automatically realized by hardware inside the chip, but are not limited to this. The realization process follows the bus specification. Here, in the operation process of the first bus (or the second bus), physical signals related to the bus protocol can be transmitted for control, and valid data can also be transmitted to each hardware controller via the physical data channel.

[0286] According to another aspect of the embodiment of the present application, there is further provided a startup control device for an embedded system for implementing the above startup control method for an embedded system. Figure 12 is a structural block diagram of a startup control device for an embedded system according to an embodiment of the present application. As shown in Figure 12, the device includes: a first control unit 1202 for controlling an operating state of a target device by controlling a hardware controller of the target device via a first bus by a first operating system running on a first processor core of a processor, wherein the embedded system comprises: a first control unit 1202 including the first operating system; a start-up unit 1204 coupled to the first control unit 1202 and configured to guide a second operating system to start on a second processor core of the processor, wherein the embedded system further includes a second operating system, the response speed of the first operating system is higher than that of the second operating system, and the first operating system and the second operating system communicate via a second bus, the bandwidth of the second bus being higher than that of the first bus; a first execution unit 1206 coupled to the startup unit 1204 for taking over control of the target device by the second operating system after the second operating system is started by taking over the hardware controller via the first bus.

[0287] It should be noted that the first control unit 1202 in this embodiment may be used to perform the above step S202, the starting unit 1204 in this embodiment may be used to perform the above step S204, and the first execution unit 1206 in this embodiment may be used to perform the above step S206.

[0288] The above module controls the operating state of the target device by having a first operating system running on a first processor core of the processor control the hardware controller of the target device via a first bus, wherein the embedded system includes a first operating system and guides a second operating system to start up on a second processor core of the processor, wherein the embedded system further includes a second operating system, the response speed of the first operating system is faster than that of the second operating system, the first operating system and the second operating system communicate via a second bus, the bandwidth of the second bus is higher than that of the first bus, and after the second operating system is started up, the second operating system takes over the hardware controller via the first bus, thereby taking over control of the target device, thereby solving the problem in the related art that the operating system startup control method requires the addition of an additional chip, resulting in high device costs, saving hardware costs, and improving device control scalability.

[0289] In one exemplary embodiment, the first control unit a first execution module for executing a first control task of a first operating system on a first processor core, where the first control task is used to control a hardware controller; a reading module for reading sensor data of a predetermined sensor corresponding to the target device by a first processor core; and a first transmitting module for transmitting an equipment control command to the hardware controller via the first bus based on sensor data from a predetermined sensor according to the first control task, thereby causing the hardware controller to control the operating state of the target equipment based on the equipment control command.

[0290] In one exemplary embodiment, the first transmitting module comprises: a first determination submodule for determining a target parameter value of an equipment operation parameter of a target equipment based on sensor data of a predetermined sensor through a first control task, wherein the equipment operation parameter is a parameter for controlling the operation state of the target equipment; and a sending sub-module for sending an equipment control command including a target parameter value to the hardware controller via the first bus according to the first control task.

[0291] In one exemplary embodiment, the first determining sub-module: If the target device is a fan, a determination subunit is included for determining, according to the first control task, a target parameter value of a fan operation parameter of the fan based on sensor data of a predetermined sensor.

[0292] In one exemplary embodiment, the decision subunit comprises: When the target device is a fan and the specified sensor is a temperature sensor, a determination second subunit is included for determining a target rotational speed value of the fan based on sensor data of the temperature sensor by the first control task, where the fan rotational speed has a positive correlation with the temperature detected by the temperature sensor.

[0293] In one exemplary embodiment, the first execution unit: a second transmitting module for transmitting, by the second operating system, a first inter-core interrupt to the first operating system via the second bus, wherein the first inter-core interrupt is used to request takeover of a hardware controller by the second operating system; and a control module for controlling the hardware controller via the first bus by a second control task of the second operating system when the first operating system receives a second inter-core interrupt in response to the first inter-core interrupt to indicate consent to the second operating system taking over the hardware controller, wherein the second control task is a control module used to control the hardware controller.

[0294] In one exemplary embodiment, the device comprises: a second control unit that transmits a first inter-core interrupt to the first operating system via a second bus by the second operating system, and then controls a third control task of the first operating system to sleep in response to the received first inter-core interrupt, where the third control task is used to control a hardware controller; It further includes a first transmitting unit for transmitting, by the first operating system, a second inter-core interrupt to the second operating system via the second bus when the third control task has already gone to sleep.

[0295] In one exemplary embodiment, the device comprises: A second execution unit for pushing system operation data of the first operating system onto the stack when the third control task has already gone to sleep, wherein the second inter-core interrupt further includes a second execution unit used to instruct the second operating system to take over the first processor core.

[0296] In one exemplary embodiment, the device comprises: a wake-up unit for waking up the first processor core by the processor after a chip on which the processor is located is powered on before a first operating system running on the first processor core of the processor controls a hardware controller of the target device via a first bus; and a running unit for guiding the first operating system to start up on the first processor core by running a boot loader program of the first operating system by the first processor core.

[0297] In one exemplary embodiment, the initiation unit comprises: a second execution module for executing the second program loader by the first processor core, thereby waking up the second processor core with the second program loader; and a running module for guiding the second operating system to start on the first processor core by running a generic boot loader of the second operating system by the second processor core.

[0298] In one exemplary embodiment, the device comprises: a third execution unit for taking over control of the target device by 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 when the second operating system is to be restarted after the second operating system has taken over the hardware controller via the first bus; and a third control unit for controlling the second operating system to restart the system.

[0299] In one exemplary embodiment, the third execution unit: and a transmitting module for transmitting, by the second operating system, a system wake-up interrupt to the first operating system via the second bus to wake up the first operating system when the second operating system is to be restarted.

[0300] In one exemplary embodiment, the device comprises: a first allocation unit for allocating a group of allocation target services to a corresponding operating system among a first operating system and a second operating system according to a resource dynamic allocation rule, where the resource dynamic allocation rule includes: performing resource dynamic allocation based on at least one of a service response speed, a service resource occupancy rate, a service coupling degree, and a service importance; a first determination unit for determining a resource allocation result corresponding to the group of allocated services, where the resource allocation result is used to indicate a processing resource of a processor corresponding to each allocated service among the group of allocated services, the processing resource of the processor including a processor core; The system further includes a second allocation unit for allocating the processing resources of the processor to the first operating system and the second operating system based on the operating systems corresponding to the services to be allocated and the resource allocation results.

[0301] In one exemplary embodiment, the first allocation unit comprises: a first allocation module for allocating to a first operating system those services among the group of services to be allocated that have a service response speed requirement equal to or greater than a set response speed threshold, and for allocating to a second operating system those services among the group of services to be allocated that have a service response speed requirement less than the set response speed threshold; a second allocation module for allocating to a first operating system those services to be allocated that have a service resource occupancy rate less than a first occupancy rate threshold among the services to be allocated in one group, and for allocating to a second operating system those services to be allocated that have a traffic resource occupancy rate equal to or greater than the first occupancy rate threshold among the services to be allocated in one group; A third allocation module for allocating a service to be allocated that includes sensitive information from among the services to be allocated from one group to a target operating system, wherein the target operating system includes at least one of the first operating system and the second operating system, which is an operating system that interacts less frequently with the target of use, according to the third allocation module.

[0302] In one exemplary embodiment, the first allocation unit comprises: a fourth allocation module for allocating to the first operating system a service to be allocated among the services to be allocated in one group, the service having a service coupling degree with an already allocated service of the first operating system equal to or greater than a first coupling degree threshold; and a fifth allocation module for allocating to the second operating system a service to be allocated among the services to be allocated in one group, the service coupling degree with an already allocated service of the second operating system being equal to or greater than a second coupling degree threshold.

[0303] In one exemplary embodiment, the first determining unit comprises: The system includes a generation module for generating a resource mapping table of the services to be allocated to one group and the processing resources of the processor by linking the resource usage status of the processing resources of the first operating system and the resource usage status of the processing resources of the second operating system based on the allocation results of the services to be allocated to one group.

[0304] In one exemplary embodiment, the second allocation unit: The sixth allocation module allocates the unallocated processing resource to an operating system to which the service to be allocated corresponding to the unallocated processing resource is allocated when it is determined based on the resource allocation result that a service to be allocated corresponding to the unallocated processing resource exists in an unallocated processing resource among the processing resources of the processor.

[0305] In one exemplary embodiment, the device comprises: a second sending unit for sending target data to a target virtual channel in the memory of the processor by the first operating system; a third sending unit for sending an interrupt notification message to the second operating system; and an acquisition unit for acquiring target data from the target virtual channel in the memory by the second operating system responding to the interrupt notification message.

[0306] In one exemplary embodiment, the memory includes a data storage area and a metadata storage area, the data storage area is partitioned into a plurality of storage units, each storage unit is used to store service data, and the metadata storage area is used to store the size and occupancy status of each storage unit of the data storage area.

[0307] In one exemplary embodiment, the second transmitting unit: a third execution module for reading, by the first operating system, the record in the metadata storage area, and determining, based on the read record, at least one storage unit in the data storage area that is in an idle state and whose total space is equal to or greater than the length of the target data, to obtain a target virtual channel; and a fourth execution module for setting the state of at least one storage unit corresponding to the target virtual channel in the metadata storage area to an occupied state, and for storing the target data in the target virtual channel.

[0308] In one exemplary embodiment, the acquisition unit comprises: a fifth execution module for reading, by the second operating system, the record in the metadata storage area and determining a target virtual channel based on the read record; and a sixth execution module for obtaining target data from the at least one storage unit corresponding to the target virtual channel and setting a state of the at least one storage unit to an idle state.

[0309] In one exemplary embodiment, the data storage area includes a plurality of memory channels, each memory channel being configured by one or more storage units; the metadata storage area stores a plurality of records, each record being used to record metadata of one memory channel, and the metadata of each memory channel includes at least a channel ID of the memory channel, a size of the memory channel, and an occupied status of the memory channel; and the third execution module: a first traversal sub-module for traversing records stored in the metadata storage area to determine whether a first target record exists, the first target record indicating that the memory channel is in an idle state and that the size of the memory channel is equal to or greater than the length of the target data; and a second determination submodule for determining, if the first target record exists, a memory channel indicated by a channel ID recorded in the first target record as a target virtual channel.

[0310] In one exemplary embodiment, when the memory channel is occupied, the metadata of the memory channel further includes an ID of a source CPU core of the target data and an ID of a destination CPU core of the target data, and the fifth execution module: a second traversal sub-module for traversing the records stored in the metadata storage area to determine whether a second target record exists, where the second target record indicates that the memory channel is in an occupied state, and the ID of the destination CPU core is the ID of a CPU core of a second operating system, and the ID of the source CPU core is not the ID of a CPU core of the second operating system; and a third determination submodule that, if the second target record exists, determines the memory channel indicated by the channel ID recorded in the second target record as the target virtual channel.

[0311] In one exemplary embodiment, the device comprises: a fourth execution unit for receiving a memory application command of the first operating system and performing a lock operation on the memory of the processor, where the memory application command is used to apply for use of the memory of the processor; a fifth execution unit for reading an occupied state of the memory if the lock on the memory is successful, and determining whether there is a free target memory space in the memory based on the occupied state of the memory, where the size of the target memory space is equal to or greater than the size of the memory applied for by the memory application command; The memory further includes a feedback unit for, if the target memory space exists, feeding back address information of the target memory space to the first operating system and updating the occupied status of the memory.

[0312] In one exemplary embodiment, the memory includes a metadata storage area in which a state mapping table for storing an occupied state of the data storage area is stored, and a data storage area for storing service data, and the fifth execution unit: A seventh execution module is included for reading the record in the state mapping table from the metadata storage area, and determining whether the target memory space exists in the data storage area based on the record in the state mapping table.

[0313] In one exemplary embodiment, the device comprises: a determining unit for determining whether the memory is currently in a locked state before executing a lock operation on the memory of the processor, wherein the locked state indicates that the memory is in a state offered for use; and a sixth execution unit for performing a lock operation on the memory if the memory is not currently in a locked state.

[0314] In one exemplary embodiment, the device comprises: The memory further includes a release unit for reading the occupied state of the memory and determining whether or not there is a free target memory space in the memory based on the occupied state of the memory, and then releasing the lock on the memory if there is no free target memory space in the memory.

[0315] Each of the above modules may be realized by software or hardware, and if realized by hardware, the above modules may all be located on the same processor, or the above modules may be located on different processors in any combination, but this is not limited to this. An embodiment of the present application further provides a chip including at least one of a programmable logic circuit and an executable command, the chip being run in an electronic device to implement the steps in any one of the above method embodiments.

[0316] An embodiment of the present application further provides a BMC chip including: a memory unit for storing a program; and a processing unit, connected to the memory unit, for running the program so as to perform the steps in any one of the above method embodiments. An embodiment of the present application further provides a main board including at least one processor and at least one memory unit for storing at least one program, which, when executed by the at least one processor, causes the at least one processor to realize the steps in any one of the above method embodiments.

[0317] An embodiment of the present application further provides a server including a processor, a communication interface, a memory unit, and a communication bus, wherein the processor, the communication interface, and the memory unit realize communication between each other via the communication bus, the memory unit is used to store a computer program, and when the processor executes the program stored in the memory unit, it realizes the steps in any one of the above method embodiments and achieves the same technical effect.

[0318] The communication bus of the server may be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus, etc. This communication bus may be divided into an address bus, a data bus, a control bus, etc. The communication interface is used for communication between the server and other devices.

[0319] The storage may include RAM, NVM (Non-Volatile Memory), e.g., at least one magnetic disk storage. Optionally, the storage may be at least one storage device located remotely from the processor. The processor may be a general-purpose processor, including a CPU, a NP (Network Processor), a DSP (Digital Signal Processor), an ASIC, an FPGA or other programmable logic device, a discrete gate or transistor logic device, or a discrete hardware component.

[0320] An embodiment of the present application further provides a computer-readable storage medium having stored thereon a computer program configured to perform the steps of any one of the above method embodiments when run. In one exemplary embodiment, the computer-readable storage medium may include various media capable of storing a computer program, such as, but not limited to, a USB memory, a ROM, a RAM, a removable hard disk, a magnetic disk, or an optical disk.

[0321] An embodiment of the present application further provides an electronic device including a memory unit and a processor, wherein a computer program is stored in the memory unit, and the processor is configured to execute the steps of any one of the above method embodiments by running the computer program.

[0322] In one exemplary embodiment, the electronic device may include a transmission device and an input / output device, where the transmission device is connected to the processor and the input / output device is connected to the processor. For specific examples in this embodiment, reference can be made to the examples described in the above embodiments and exemplary embodiments, and this embodiment will not be further described here.

[0323] As will be apparent to those skilled in the art, each module or step of the present application described above may be implemented by a general-purpose computing device, integrated into a single computing device, or distributed across a network of multiple computing devices, implemented by program code executable by a computing device, thereby storing the code in a storage device and executing the code on the computing device, and in some cases, performing the steps shown or described in an order different from that described herein, or fabricating the steps into individual integrated circuit modules, or fabricating multiple modules or steps therein into a single integrated circuit module. Thus, the present application is not limited to any particular combination of hardware and software.

[0324] The above are only selective examples of the present application and are not intended to limit the present application, and those skilled in the art may have various modifications and variations to the present application. All modifications, equivalent replacements, improvements, etc. made within the scope of the principles of the present application shall be included within the protection scope of the present application.

Claims

1. A startup control method for an embedded system, comprising: controlling an operating state of a target device by controlling a hardware controller of the target device via a first bus by a first operating system running on a first processor core of a processor, wherein the embedded system includes the first operating system; and guiding a second operating system to start on a second processor core of the processor, wherein the embedded system further includes the second operating system, the response speed of the first operating system is higher than that of the second operating system, the first operating system and the second operating system communicate via a second bus, and a bandwidth of the second bus is higher than a bandwidth of the first bus; and after the second operating system is started, the second operating system takes over control of the target device by taking over the hardware controller via the first bus.

2. Controlling a hardware controller of a target device via a first bus by a first operating system running on a first processor core of a processor, executing a first control task of the first operating system on the first processor core, wherein the first control task is used to control the hardware controller; reading sensor data of a predetermined sensor corresponding to the target device by the first processor core; 2. The method of claim 1, further comprising: transmitting, via the first control task, an equipment control command to the hardware controller via the first bus based on sensor data from the predetermined sensor, thereby controlling, via the hardware controller, the operational state of the target equipment based on the equipment control command.

3. transmitting, by the first control task, an equipment control command to the hardware controller via the first bus based on sensor data of the predetermined sensor; determining, by the first control task, a target parameter value of an equipment operation parameter of the target equipment based on sensor data of the predetermined sensor, wherein the equipment operation parameter is a parameter for controlling an operation state of the target equipment; 3. The method of claim 2, further comprising: transmitting, by the first control task, the equipment control command including the target parameter value to the hardware controller via the first bus.

4. determining, by the first control task, a target parameter value of an equipment operation parameter of the target equipment based on sensor data of the predetermined sensor; 4. The method of claim 3, wherein if the target equipment is a fan, the first control task includes determining a target parameter value for a fan operation parameter of the fan based on sensor data from the predetermined sensor.

5. When the target device is a fan, determining a target parameter value of a fan operation parameter of the fan based on sensor data of the predetermined sensor by the first control task includes:

5. The method of claim 4, wherein, when the target device is a fan and the predetermined sensor is a temperature sensor, the first control task includes determining a target rotational speed value of the fan based on sensor data of the temperature sensor, wherein the rotational speed of the fan has a positive correlation with the temperature detected by the temperature sensor.

6. Taking over the hardware controller via a first bus by the second operating system includes: sending, by the second operating system, a first inter-core interrupt to the first operating system via the second bus, wherein the first inter-core interrupt is used to request takeover of the hardware controller by the second operating system; 2. The method of claim 1, further comprising: when the first operating system receives a second inter-core interrupt in response to the first inter-core interrupt to indicate consent to the second operating system taking over the hardware controller, controlling the hardware controller via the first bus by a second control task of the second operating system, wherein the second control task is used to control the hardware controller.

7. Allocating a group of allocation target services to corresponding operating systems among the first operating system and the second operating system according to a resource dynamic allocation rule, wherein the resource dynamic allocation rule includes performing resource dynamic allocation based on at least one of a service response speed, a service resource occupancy rate, a service coupling degree, and a service importance, and the service coupling degree is for representing a degree of association between the allocation target services and already allocated services in each operating system; determining a resource allocation result corresponding to the one group of allocated services, wherein the resource allocation result is used to indicate a processing resource of the processor corresponding to each allocated service of the one group of allocated services, the processing resource of the processor including a processor core; 2. The method of claim 1, further comprising: allocating processing resources of the processor to the first operating system and the second operating system based on the resource allocation result and an operating system corresponding to each of the services to be allocated.

8. a first control unit for controlling an operating state of a target device by controlling a hardware controller of the target device via a first bus by a first operating system running on a first processor core of a processor, wherein the embedded system includes a first control unit including the first operating system; a startup unit for guiding a second processor core of the processor to start a second operating system, wherein the embedded system further includes the second operating system, the response speed of the first operating system is higher than that of the second operating system, the first operating system and the second operating system communicate via a second bus, and a bandwidth of the second bus is higher than that of the first bus; a first execution unit for taking over control of the target device by having the second operating system take over the hardware controller via the first bus after starting the second operating system.

9. A computer-readable storage medium having stored thereon a computer program which, when executed by a processor, implements the steps of the method according to any one of claims 1 to 7.

10. An electronic device comprising: a memory unit; a processor; and a computer program that is stored in the memory unit and can be run by the processor, wherein when the computer program is executed by the processor, the electronic device realizes the steps of the method according to any one of claims 1 to 7.

Images