A Method for Booting and Interrupt Affinity Management of Heterogeneous Operating Systems on Multi-core Processors
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-07-15
- Publication Date
- 2026-08-14
AI Technical Summary
1）单一操作系统对应单一核心，无法在AMP环境下实现单一操作系统管理多个核心，也无法将任意核心作为启动核心
1）本发明提供一种多核处理器异构操作系统启动与中断亲和性管理方法，可以在AMP环境下的操作系统中支持以任意核心作为启动核心，镜像无需重新编译；通过单一操作系统管理多个核心，实现单一操作系统结合多核心的复合模式，支持通过一个操作系统对应多个核心的动态核心管理方法，有效增强多操作系统与多核心组合的扩展能力。
Smart Images
Figure CN122570404A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the technical field of multi-core heterogeneous processor operating systems, specifically to a method for managing the startup and interrupt affinity of a multi-core processor heterogeneous operating system. Background Technology
[0002] Existing AMP (Asymmetric Multiprocessing) architectures typically use a static approach to assign a unique boot kernel to each operating system (OS), meaning an OS can only run on one CPU core. If an operating system is desired to use multiple cores, it must be switched to an SMP (Symmetric Multiprocessing) scheme, but this will conflict with other operating systems.
[0003] For example, its typical architecture, OpenAMP, is a one-core-one-OS architecture, which cannot achieve a single operating system managing multiple cores. It explicitly specifies which core the operating system runs on in the resource table through the remoteproc API (start() / stop()), and the CPU ID is fixedly bound in the resource table and cannot be changed at runtime. Furthermore, its multi-core heterogeneous inter-core communication IPCC also needs to be bound according to the core.
[0004] Existing virtualization solutions differ from AMP. Virtualization solutions use a hypervisor for tightly coupled scheduling, while AMP has no scheduler and relies entirely on hardware mapping. Furthermore, most AMP boot processes depend on the boot core number embedded in the image, requiring images to be recompiled for different cores. Interrupt routing is also static; the Serial Peripheral Bus Interface (SPI) interrupt cannot automatically bind to the physical core upon first enable, and frequent enabling or disabling can easily disrupt affinity. The mapping mechanism between logical core IDs and physical core IDs relies on the Board Support Package (BSP) and lacks a unified interface, resulting in inconsistent performance of inter-core interrupts (IPI) and interrupt affinity across different AMP configurations.
[0005] Therefore, the main defects and shortcomings of the existing AMP solution in practical use include: 1) A single operating system corresponds to a single core. It is impossible to manage multiple cores with a single operating system in an AMP environment, nor is it possible to use any core as the boot core.
[0006] 2) Interrupt routing is static in the AMP environment and cannot be automatically bound: Each operating system needs to configure fixed interrupt affinity on its own generic interrupt controller (GIC). At the same time, repeated enable / disable operations can easily cause confusion, and there is a lack of mature solutions for automatic binding during the first enable operation.
[0007] 3) Inter-core interrupts (IPI) lack a unified mapping, and there are significant differences between different operating systems, different board support packages, and different vendor platforms.
[0008] 4) The boot kernel cannot be dynamically configured.
[0009] Therefore, there is an urgent need to provide a new solution to address the defects and shortcomings of the existing technologies. Summary of the Invention
[0010] To address the shortcomings and deficiencies in existing technologies, this invention provides a method for managing the startup and interrupt affinity of heterogeneous operating systems on multi-core processors.
[0011] The specific solution provided by this invention is as follows: A method for booting and interrupt affinity management of a heterogeneous operating system for a multi-core processor, characterized in that the method includes the following steps: S100: After the first core starts up, it obtains the set of manageable cores corresponding to the operating system through the system information table and device tree, and wakes up the other cores in the set of manageable cores except for the first core. S200: The started core determines whether it is the first core of the system, obtains the logical core ID corresponding to the first core based on the physical core ID of the started core, and establishes a mapping table containing the mapping relationship between logical core ID and physical core ID; S300: Sets the interrupt flag for the serial peripheral bus interface; S400: Through the established mapping table, the logical core ID visible to the current operating system is converted into the physical core ID, and the target CPU affinity mask is generated after the core ownership verification is successful.
[0012] As a further preferred embodiment of the present invention, a system information table of heterogeneous operating systems is established before step S100; Furthermore, the system information table includes at least the current operating system identifier, target operating system identifier, operating system type, boot physical core, number of manageable cores, image entry information, image loading address, device tree loading address, shared memory address and size, inter-core interrupt number, and inter-core interrupt affinity information; When the target operating system starts, the target operating system description is queried according to the target operating system identifier, the target operating system status is set to booting, and the image loading method is selected according to the target operating system type. The boot physical kernel of the target operating system is woken up through the core control interface. If the wake-up is successful, the target operating system state will be set to running state; if the wake-up fails, the target operating system state will be set to error state.
[0013] As a further preferred embodiment of the present invention, in step S100, The core components in the manageable core set must simultaneously satisfy: 1) It has already been declared in the processor node; 2) Not marked as occupied by other operating systems; 3) Matches the range defined by the current multi-core processor partition; The wake-up method involves triggering the target core to power on via the power state coordination interface and then jumping to the auxiliary entry point.
[0014] As a further preferred embodiment of the present invention, step S200, when the core has been activated to determine whether it is the system's primary core, includes the following steps: S201: Read the global control block of the multi-core processor; S202: Determine the startup flag: S2021: When the startup flag is in a not started state, The current processor attempts to write the boot physical core ID to the booted core. If the writing is successful, the booted core is determined to be the system's first core, and the boot flag is set to the booted state. If the writing fails, the booted core is determined to be a non-system first core. S022: When the startup flag is set to the started state, If the currently started core is determined to be a non-system first core, the current processor reads the registered physical core ID of the startup core and generates the logical core ID of the current core based on the correspondence between the physical core ID of the currently started core and the physical core ID of the startup core.
[0015] As a further preferred embodiment of the present invention, in step S200, when obtaining the logical core ID corresponding to the first core based on the physical core ID of the activated core and establishing a mapping table containing the mapping relationship between the logical core ID and the physical core ID: When a started core determines that it is the first core of the system, it reads the physical core ID of the started core and registers it as the first core physical core ID. At the same time, it establishes a mapping relationship between logical core ID and physical core ID based on the first core physical core ID, stores the logical core ID in the independent stack area corresponding to the current core, and establishes a mapping table containing the mapping relationship between logical core ID and physical core ID. When a started core determines that it is not the first core of the system, it reads the physical core ID of the started core and obtains the stored start physical core ID. It determines the mapping relationship between the current core and the first core through the correspondence between the two, generates the corresponding logical core ID based on the start physical core ID, stores the logical core ID in the independent stack area corresponding to the current core, and establishes a mapping table containing the mapping relationship between logical core ID and physical core ID. Furthermore, the mapping table supports both the conversion of logical CPU sets to physical CPU sets and the reverse conversion of physical CPU sets to logical CPU sets.
[0016] As a further preferred embodiment of the present invention, step S300 includes at least the following steps: S301: Sets the interrupt enable flag for the serial peripheral bus interface; S302: Sets the affinity interrupt flag for the serial peripheral bus interface.
[0017] As a further preferred embodiment of the present invention, step S301 includes the following steps: S3011: Enter the interrupt enable function and adjust the settings; S3012: Determine whether the interrupt number has been marked; if it has been marked, proceed to step S3014; if it has not been marked, proceed to step S3013. S3013: Enable interrupt number flag and set default interrupt affinity attribute; S3014: End of enable interrupt flag.
[0018] As a further preferred embodiment of the present invention, step S302 includes the following steps: S3021: Enter the interrupt affinity function and adjust the settings; S3022: Determine whether the affinity interruption number has been marked; if it has been marked, proceed to step S3024; if it has not been marked, proceed to step S3023. S3023: Perform affinity interruption marking; S3024: Set interrupt affinity attribute.
[0019] As a further preferred embodiment of the present invention, setting an interrupt flag for the serial peripheral bus interface is executed on the target core corresponding to the target CPU affinity mask; if the currently executing core is not the target core, the interrupt flag is set on the target core through cross-core calls or execution context binding.
[0020] As a further preferred embodiment of the present invention, step S400 includes the following steps: S401: Receive the logical core ID of the core currently being started; S402: Query the mapping table; S403: Obtain the physical core ID corresponding to the logical core ID of the currently booting core; S404: Perform core attribution verification, including: 1) Verify whether the target physical core has been declared in the processor node or system information table; 2) Verify whether the target physical core belongs to the manageable core set of the current operating system; 3) Verify whether the target physical core is not occupied by other operating systems and whether it is consistent with the current operating system identifier; If any of the above conditions are not met, the affinity mask corresponding to the target physical core will be rejected or the interrupt binding will be rejected. S405: Output a target CPU affinity mask, which includes a set of bitmaps consisting of one or more target physical cores, and the target CPU affinity mask is bound to the context of interrupt delivery, inter-core interrupt transmission, or interrupt handling.
[0021] Compared with existing technologies, the technical effects that this invention can achieve include: 1) This invention provides a method for managing the boot and interrupt affinity of heterogeneous operating systems for multi-core processors, which can support any core as the boot core in the operating system under the AMP environment without recompiling the image; it manages multiple cores through a single operating system, realizing a composite mode of a single operating system combined with multiple cores, and supports a dynamic core management method that allows one operating system to correspond to multiple cores, effectively enhancing the scalability of multi-operating system and multi-core combinations.
[0022] 2) This invention provides a method for managing the startup and interrupt affinity of a heterogeneous operating system for a multi-core processor. When the Serial Peripheral Bus Interface (SPI) interrupt is enabled for the first time, it can achieve automatic binding design and set the corresponding interrupt flag. By setting an enable interrupt flag and an affinity interrupt flag for the SPI, the SPI interrupt when enabled for the first time will be bound according to the physical core topology of the current operating system. The SPI interrupt that performs interrupt affinity setting for the first time will also be bound to and marked with the physical core of the operating system, and will not be overwritten by subsequent enable / disable operations, thus ensuring the stability of interrupt affinity.
[0023] 3) This invention provides a method for managing the startup and interrupt affinity of a heterogeneous operating system for multi-core processors. By introducing a unified mapping framework, the CPU mapping table, which converts logical core IDs to physical core IDs, and further supporting the conversion between logical CPU sets and physical CPU sets, the configuration of interrupt affinity, thread affinity, and inter-core interrupt behavior can be kept consistent across all AMP environments.
[0024] 4) This invention provides a method for managing the startup and interrupt affinity of a heterogeneous operating system for multi-core processors. It solves the problem of no data during the startup phase by using a startup flag, ensures reliable and controllable first core determination, and determines the subsequent core logic number by combining the startup physical core ID with the system information table.
[0025] 5) This invention provides a method for managing the startup and interrupt affinity of heterogeneous operating systems for multi-core processors. By using the heterogeneous operating system system information table, the inter-core interrupt abstraction layer, and the communication route from the operating system identifier to the core and interrupt number, cross-operating system communication modules such as virtual shared memory and virtual network can reuse a unified core attribution and interrupt affinity strategy, thereby avoiding misdelivery of cross-operating system notifications. Attached Figure Description
[0026] Figure 1 The diagram shows the steps of the management method provided by the present invention.
[0027] Figure 2 The diagram shown is a flowchart of step S301 in the management method provided by the present invention.
[0028] Figure 3 The diagram shown is a flowchart of step S302 in the management method provided by the present invention.
[0029] Figure 4 The diagram shown illustrates the mapping relationship between logical core ID and physical core ID provided by this invention. Detailed Implementation
[0030] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.
[0031] In the description of this invention, it should be noted that the terms "upper," "lower," "inner," "outer," "front end," "rear end," "both ends," "one end," and "the other end," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are used only for the convenience of describing this invention and for simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on this invention. Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance.
[0032] In the description of this invention, it should be noted that, unless otherwise explicitly specified and limited, the terms "installed," "equipped with," "connected," etc., should be interpreted broadly. For example, "connection" can be a fixed connection, a detachable connection, or an integral connection; it can be a mechanical connection or an electrical connection; it can be a direct connection or an indirect connection through an intermediate medium; it can be a connection within two components. Those skilled in the art can understand the specific meaning of the above terms in this invention based on the specific circumstances.
[0033] [First Embodiment] like Figure 1 As shown, the first embodiment of the present invention provides a method for booting and interrupt affinity management of a heterogeneous operating system for a multi-core processor, comprising the following steps: S100: After the first core starts up, it obtains the set of manageable cores corresponding to the operating system through the system information table and device tree, and wakes up other cores within the set of manageable cores; Before step S100, a system information table for heterogeneous operating systems is established; The system information table in this embodiment includes at least the current operating system identifier, target operating system identifier, operating system type, boot physical core, number of manageable cores, image entry information, image loading address, device tree loading address, shared memory address and size, inter-core interrupt number, and inter-core interrupt affinity information. When the target operating system starts, the target operating system description is queried according to the target operating system identifier, the target operating system status is set to booting, and the image loading method is selected according to the target operating system type. The boot physical kernel of the target operating system is woken up through the core control interface. If the wake-up is successful, the target operating system state will be set to running state; if the wake-up fails, the target operating system state will be set to error state.
[0034] In this embodiment, the cores in the manageable core set must simultaneously satisfy: 1) It has already been declared in the processor node; 2) Not marked as occupied by other operating systems; 3) Matches the range defined by the current multi-core processor partition.
[0035] The wake-up method involves triggering the target core to power on via the Battery Status Coordination Interface (PSCI) and then jumping to the secondary entry.
[0036] This aims to manage multiple cores through a single operating system, breaking through the limitations of the traditional AMP's one-core-one-system approach.
[0037] S200: The started core determines whether it is the system's first core. Based on the physical core ID of the started core, it obtains the logical core ID corresponding to the first core and establishes a mapping table containing the mapping relationship between logical core IDs and physical core IDs, so that the operating system can access the managed cores through the logical core ID. In this embodiment, when the core has been activated to determine whether it is the system's primary core, the following steps are included: S201: Read the global control block of the multi-core processor; S202: Determine the startup flag: S2021: When the startup flag is in a not started state, The current processor attempts to write the boot physical core ID to the booted core. If the writing is successful, the booted core is determined to be the system's first core, and the boot flag is set to the booted state. If the writing fails, the booted core is determined to be a non-system first core. S022: When the startup flag is set to the started state, If the currently started core is determined to be a non-system first core, the current processor reads the registered physical core ID of the startup core and generates the logical core ID of the current core based on the correspondence between the physical core ID of the currently started core and the physical core ID of the startup core.
[0038] In step S200, when obtaining the logical core ID corresponding to the first core based on the physical core ID of the started core and establishing a mapping table containing the mapping relationship between logical core IDs and physical core IDs: When a started core determines that it is the first core of the system, it reads the physical core ID of the started core and registers it as the first core physical core ID. At the same time, it establishes a mapping relationship between logical core ID and physical core ID based on the first core physical core ID, stores the logical core ID in the independent stack area corresponding to the current core, and establishes a mapping table containing the mapping relationship between logical core ID and physical core ID. When a started core determines that it is not the first core of the system, it reads the physical core ID of the started core and obtains the stored start physical core ID, which is also the first core physical core ID. It determines the mapping relationship between the current core and the first core through the correspondence between the two, and generates the corresponding logical core ID based on the start physical core ID. It stores the logical core ID in the independent stack area corresponding to the current core and establishes a mapping table containing the mapping relationship between logical core ID and physical core ID. Furthermore, the mapping table supports both conversion from logical CPU sets to physical CPU sets and vice versa. When the upper-layer operating system passes in a logical CPU set, it iterates through the valid logical core IDs in the logical CPU set, obtains the corresponding physical core IDs through the mapping table, and generates a physical CPU set or target CPU affinity mask. When it is necessary to return CPU information to the upper layer, the physical CPU set is converted back to a logical CPU set. This ensures that interrupt affinity, thread affinity, and inter-core interrupt behavior are configured consistently across all AMP environments, achieving the goal of enabling the operating system to boot from any core.
[0039] The mapping table is used to establish a unified mapping relationship between logical core IDs and physical core IDs in a multi-core processor. It also records the operating system ownership information and interrupt affinity information corresponding to each logical core, so as to realize unified scheduling and isolation control of inter-core interrupts, peripheral interrupts and operating system core resource access.
[0040] In this embodiment, S300: Set the interrupt flag for the serial peripheral bus interface; this includes at least the following steps: S301: Sets the interrupt enable flag for the serial peripheral bus interface; S302: Sets the affinity interrupt flag for the serial peripheral bus interface.
[0041] like Figure 2 As shown, step S301 includes the following steps: S3011: Enter the interrupt enable function and adjust the settings; S3012: Determine whether the interrupt number has been marked; if it has been marked, proceed to step S3014; if it has not been marked, proceed to step S3013. S3013: Enable interrupt number flag and set default interrupt affinity attribute; S3014: End of enable interrupt flag.
[0042] like Figure 3 As shown, step S302 includes the following steps: S3021: Enter the interrupt affinity function and adjust the settings; S3022: Determine whether the affinity interruption number has been marked; if it has been marked, proceed to step S3024; if it has not been marked, proceed to step S3023. S3023: Perform affinity interruption marking; S3024: Set interrupt affinity attribute.
[0043] The default interrupt affinity attribute set during the interrupt enabling process is used to establish the initial binding baseline for interrupts, ensuring that interrupts have a deterministic delivery target when they are first enabled; the affinity interrupt marking process is used to make strategic adjustments based on the initial binding baseline, so as to realize dynamic binding control of interrupts in different operating systems and multi-core environments.
[0044] It is worth noting that in this embodiment, setting the interrupt flag for the serial peripheral bus interface is executed on the target core corresponding to the target CPU affinity mask; if the current execution core is not the target core, the interrupt flag is set on the target core through cross-core calls or execution context binding.
[0045] By setting an enable interrupt flag and an affinity interrupt flag for the serial peripheral bus interface, the serial peripheral bus interface interrupts when first enabled will be bound to the physical core topology of the current operating system, and the serial peripheral bus interface interrupts for the first time interrupt affinity settings will also be bound to and marked with the physical core of the operating system, and will not be overwritten by subsequent enable or disable operations, thus ensuring the stability of interrupt affinity.
[0046] S400: By establishing a mapping table, it converts the logical core ID visible to the current operating system into the physical core ID, and generates the target CPU affinity mask after the core ownership verification is successful, so as to shield the hardware differences from the upper-layer operating system and make all interrupt affinity APIs consistent under any AMP configuration.
[0047] Step S400 in this embodiment includes the following steps: S401: Receive the logical core ID of the core currently being started; S402: Query the mapping table; S403: Obtain the physical core ID corresponding to the logical core ID of the currently booting core; S404: Perform core attribution verification, including: 1) Verify whether the target physical core has been declared in the processor node or system information table; 2) Verify whether the target physical core belongs to the manageable core set of the current operating system; 3) Verify whether the target physical core is not occupied by other operating systems and whether it is consistent with the current operating system identifier; If any of the above conditions are not met, the affinity mask corresponding to the target physical core will be rejected or the interrupt binding will be rejected. S405: Output a target CPU affinity mask, which includes a set of bitmaps consisting of one or more target physical cores, and the target CPU affinity mask is bound to the context of interrupt delivery, inter-core interrupt transmission, or interrupt handling.
[0048] like Figure 4 The diagram shows the mapping relationship between logical core IDs and physical core IDs based on the CPU mapping management layer. The operating system accesses CPU resources through the logical CPU access interface, and the CPU mapping management layer converts the logical CPU into the corresponding physical CPU according to the preset mapping relationship, thereby realizing unified management and isolated access to physical CPU resources in a multi-operating system environment.
[0049] By establishing a mapping table, logical core IDs can be converted into corresponding physical core IDs, thus shielding hardware differences from the upper-level operating system and ensuring that all interrupt affinity API interfaces remain consistent under any multi-core processor configuration. At the same time, the established mapping table also ensures that the inter-core interrupt triggering strategy can trigger the correct physical core, effectively avoiding the occurrence of inter-core interrupt confusion.
[0050] The inter-core interrupt triggering strategy based on a unified mapping table includes receiving the logical core ID of the currently booting core, querying the physical core ID corresponding to the logical core ID through the mapping table, generating a target physical core interrupt delivery set, and triggering inter-core interrupts to the target physical core based on a general interrupt controller, thereby realizing a cross-operating system consistent inter-core communication mechanism under the abstraction of logical cores.
[0051] As a further preferred embodiment, an inter-core interrupt abstraction layer is also included. This layer includes interfaces for inter-core interrupt transmission, hardware interrupt number mapping, notification registration, notification deregistration, notification enabling, notification disabling, and receiving / distributing. Upon receiving an inter-core interrupt, the registered notification processing item is located based on the inter-core interrupt number, and the corresponding virtual shared memory, virtual network, or other cross-operating system communication module processing function is invoked.
[0052] In this embodiment, the cross-operating system communication module establishes a mapping table from kernel to operating system and interrupt number, and also establishes a mapping table from operating system identifier to interrupt-bound kernel. When the virtual shared memory or virtual network module needs to notify the target operating system, it queries the interrupt number and target kernel corresponding to the target operating system based on the target operating system identifier; if interrupt binding is enabled, inter-core interrupts are only delivered to the bound kernel of the target operating system.
[0053] By using heterogeneous operating system system information tables, inter-kernel interrupt abstraction layers, and communication routes from operating system identifiers to kernels and interrupt numbers, cross-operating system communication modules such as virtual shared memory and virtual networks can reuse unified kernel attribution and interrupt affinity strategies, thus avoiding misdelivery of cross-operating system notifications.
[0054] It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above, and that the invention can be implemented in other specific forms without departing from its spirit or essential characteristics. Therefore, the embodiments should be considered in all respects as exemplary and non-limiting, and the scope of the invention is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of equivalents of the claims are intended to be included within the present invention. No reference numerals in the claims should be construed as limiting the scope of the claims.
Claims
1. A method for managing boot and interrupt affinity of a heterogeneous operating system on a multi-core processor, characterized in that: The method includes the following steps: S100: After the first core starts up, it obtains the set of manageable cores corresponding to the operating system through the system information table and device tree, and wakes up the other cores in the set of manageable cores except for the first core. S200: The started core determines whether it is the first core of the system, obtains the logical core ID corresponding to the first core based on the physical core ID of the started core, and establishes a mapping table containing the mapping relationship between logical core ID and physical core ID; S300: Sets the interrupt flag for the serial peripheral bus interface; S400: Through the established mapping table, the logical core ID visible to the current operating system is converted into the physical core ID, and the target CPU affinity mask is generated after the core ownership verification is successful.
2. The method for managing startup and interrupt affinity of a heterogeneous operating system for a multi-core processor according to claim 1, characterized in that: Before step S100, a system information table for heterogeneous operating systems is established; Furthermore, the system information table includes at least the current operating system identifier, target operating system identifier, operating system type, boot physical core, number of manageable cores, image entry information, image loading address, device tree loading address, shared memory address and size, inter-core interrupt number, and inter-core interrupt affinity information; When the target operating system starts, the target operating system description is queried according to the target operating system identifier, the target operating system status is set to booting, and the image loading method is selected according to the target operating system type. The boot physical kernel of the target operating system is woken up through the core control interface. If the wake-up is successful, the target operating system state will be set to running state; if the wake-up fails, the target operating system state will be set to error state.
3. The method for managing startup and interrupt affinity of a heterogeneous operating system for a multi-core processor according to claim 1, characterized in that: In step S100, The core components in the manageable core set must simultaneously satisfy: 1) It has already been declared in the processor node; 2) Not marked as occupied by other operating systems; 3) Matches the range defined by the current multi-core processor partition; The wake-up method involves triggering the target core to power on via the power state coordination interface and then jumping to the auxiliary entry point.
4. The method for managing startup and interrupt affinity of a heterogeneous operating system for a multi-core processor according to claim 1, characterized in that: In step S200, when the already started core determines whether it is the system's primary core, the following steps are included: S201: Read the global control block of the multi-core processor; S202: Determine the startup flag: S2021: When the startup flag is in a not started state, The current processor attempts to write the boot physical core ID to the booted core. If the writing is successful, the booted core is determined to be the system's first core, and the boot flag is set to the booted state. If the writing fails, the booted core is determined to be a non-system first core. S022: When the startup flag is set to the started state, If the currently started core is determined to be a non-system first core, the current processor reads the registered physical core ID of the startup core and generates the logical core ID of the current core based on the correspondence between the physical core ID of the currently started core and the physical core ID of the startup core.
5. The method for managing boot and interrupt affinity of a heterogeneous operating system for a multi-core processor according to claim 4, characterized in that: In step S200, when obtaining the logical core ID corresponding to the first core based on the physical core ID of the activated core and establishing a mapping table containing the mapping relationship between logical core IDs and physical core IDs: When a started core determines that it is the first core of the system, it reads the physical core ID of the started core and registers it as the first core physical core ID. At the same time, it establishes a mapping relationship between logical core ID and physical core ID based on the first core physical core ID, stores the logical core ID in the independent stack area corresponding to the current core, and establishes a mapping table containing the mapping relationship between logical core ID and physical core ID. When a started core determines that it is not the first core of the system, it reads the physical core ID of the started core and obtains the stored start physical core ID. It determines the mapping relationship between the current core and the first core through the correspondence between the two, generates the corresponding logical core ID based on the start physical core ID, stores the logical core ID in the independent stack area corresponding to the current core, and establishes a mapping table containing the mapping relationship between logical core ID and physical core ID. Furthermore, the mapping table supports both the conversion of logical CPU sets to physical CPU sets and the reverse conversion of physical CPU sets to logical CPU sets.
6. The method for managing startup and interrupt affinity of a heterogeneous operating system for a multi-core processor according to claim 1, characterized in that: Step S300 includes at least the following steps: S301: Sets the interrupt enable flag for the serial peripheral bus interface; S302: Sets the affinity interrupt flag for the serial peripheral bus interface.
7. The method for managing boot and interrupt affinity of a heterogeneous operating system for a multi-core processor according to claim 6, characterized in that: Step S301 includes the following steps: S3011: Enter the interrupt enable function and adjust the settings; S3012: Determine whether the interrupt number has been marked; if it has been marked, proceed to step S3014; if it has not been marked, proceed to step S3013. S3013: Enable interrupt number flag and set default interrupt affinity attribute; S3014: End of enable interrupt flag.
8. The method for managing boot and interrupt affinity of a heterogeneous operating system for a multi-core processor according to claim 6, characterized in that: Step S302 includes the following steps: S3021: Enter the interrupt affinity function and adjust the settings; S3022: Determine whether the affinity interruption number has been marked; if it has been marked, proceed to step S3024; if it has not been marked, proceed to step S3023. S3023: Perform affinity interruption marking; S3024: Set interrupt affinity attribute.
9. The method for managing boot and interrupt affinity of a heterogeneous operating system for a multi-core processor according to claim 6, characterized in that: Set the interrupt flag for the serial peripheral bus interface and execute it on the target core corresponding to the target CPU affinity mask; If the current execution core is not the target core, then an interrupt flag is set on the target core through cross-core calls or execution context binding.
10. The method for managing startup and interrupt affinity of a heterogeneous operating system for a multi-core processor according to claim 1, characterized in that: Step S400 includes the following steps: S401: Receive the logical core ID of the core currently being started; S402: Query the mapping table; S403: Obtain the physical core ID corresponding to the logical core ID of the currently booting core; S404: Perform core attribution verification, including: 1) Verify whether the target physical core has been declared in the processor node or system information table; 2) Verify whether the target physical core belongs to the manageable core set of the current operating system; 3) Verify whether the target physical core is not occupied by other operating systems and whether it is consistent with the current operating system identifier; If any of the above conditions are not met, the affinity mask corresponding to the target physical core will be rejected or the interrupt binding will be rejected. S405: Output a target CPU affinity mask, which includes a set of bitmaps consisting of one or more target physical cores, and the target CPU affinity mask is bound to the context of interrupt delivery, inter-core interrupt transmission, or interrupt handling.