Start deployment and cooperative processing method for multi-core heterogeneous system

Abstract

The invention provides a multi-core heterogeneous system-oriented startup deployment and cooperative processing method, which comprises the following steps of: when the system runs, obtaining startup codes after a master core and a slave core are electrified, respectively obtaining mirror image files of Linux and RTOS (Real Time Operating System) on the basis of synchronous running and storage partition, and running the mirror image files on the master core and the slave core after moving the mirror image files; and after the heterogeneous operating system is loaded, generating an interrupt signal based on inter-core interrupt and a corresponding register through a CLINT module in the main core, and realizing data communication between the main core and each slave core based on the interrupt signal and the shared memory. By means of the method, after the system is powered on, the multiple cores can synchronously run the starting codes, and time delay and uncertainty possibly caused by one-by-one starting of the single cores are avoided; communication and data transmission among multiple cores are realized through interruption and memory sharing, the synchronism and consistency of data are ensured, and misjudgment and decision errors caused by data delay and inconsistency are avoided, so that the real-time performance of the system is remarkably improved.

Description

Technical Field

[0001] The present invention relates to the technical field of multi-core processors, and more specifically, to a startup deployment and collaborative processing method for a multi-core heterogeneous system. Background Art

[0002] Multi-core processor technology has become the mainstream of modern computers and embedded systems, integrating multiple processor cores into a single chip to improve processing power and efficiency. Multi-core processors play an important role in various applications, including high-performance computing, servers, mobile devices, and embedded systems. When multi-core processors are running for a long time, in order to ensure reliability, real-time and life, they will let the main core execute high-load tasks for different tasks and let the slave cores execute some basic services. This involves complex scheduling, and the operating system needs to coordinate and efficiently manage the resource scheduling, task allocation and communication functions of multiple cores.

[0003] Considering that the operating system management and deployment of multi-core heterogeneous processors involves complex hardware initialization, operating system loading and multi-core collaboration, this brings many challenges. Existing startup methods use virtualized scheduling management strategies, which consume a lot of software and hardware resources. Summary of the invention

[0004] The present invention aims to solve the technical problem that a large amount of software and hardware resources need to be consumed in the process of virtualized scheduling management strategy in the prior art, and provides a startup deployment and collaborative processing method for multi-core heterogeneous systems.

[0005] The present invention provides a startup deployment and collaborative processing method for a multi-core heterogeneous system, comprising:

[0006] Step S1, after the system is powered on, multiple cores synchronously run the startup code, and cluster based on the hart_id of each core processor to determine a master core and multiple slave cores, wherein the master core and each slave core include multiple core processors to form a corresponding cluster;

[0007] Step S2, pre-store the operating system boot image file, determine the storage location of the heterogeneous operating system, the heterogeneous operating system includes the Linux operating system and the RTOS operating system, when the system is running, the master core and each slave core obtain the boot code after powering on, obtain the Linux operating system and the RTOS operating system from the storage location respectively, run the Linux operating system on the master core, and run the RTOS operating system on each slave core;

[0008] Step S3, after the heterogeneous operating system is loaded, an interrupt signal is generated by the CLINT module in the master core based on the inter-core interrupt and the corresponding register, and data communication between the master core and each of the slave cores is achieved based on the interrupt signal.

[0009] Based on the above technical solution, the present invention can also make the following improvements.

[0010] Optionally, in step S1, after the system is powered on, multiple cores synchronously run the startup code, and cluster based on the hart_id of each core processor to determine the master core and multiple slave cores, including:

[0011] All core processors are clustered in a manner that every 4 core processors form a cluster, the first cluster being the master core and the other clusters being slave cores.

[0012] Optionally, in step S2, when the system is running, the master core and each slave core simultaneously obtain the startup code, obtain the Linux operating system and the RTOS operating system from the storage location respectively, run the Linux operating system on the master core, and run the RTOS operating system on each slave core, including:

[0013] Burn the Image file copied from the Linux operating system, the EIF file compiled from the RTOS operating system, and the UBOOT boot tool used for system startup into different sectors of the partitioned SD card;

[0014] When the system is powered on, the main core reads the boot code from FLASH into SRAM1. The boot code includes DDR initialization of each core processor, reading the UBOOT boot tool from the sector of the SD card into DDR, and jumping to the UBOOT boot tool to start;

[0015] In the RISC-V architecture, the master core and each slave core simultaneously read the boot code in SRAM1, and read the Linux operating system or RTOS operating system from different sectors of the SD card. Based on the UBOOT boot tool, the Linux operating system runs on the master core and the RTOS operating system runs on each slave core.

[0016] Optionally, during the UBOOT boot tool running phase, the Opensbi of different sectors in the SD card, the Image image file of the Linux operating system, the ELF file of the RTOS operating system, the device tree and the file system are read and loaded into the corresponding memory address;

[0017] During runtime, the Linux operating system performs the initial startup. At the same time, the UBOOT boot tool guides the saved RTOS operating system to the DDR of each slave core, sets the clock and bus status of the core processor corresponding to the HART_ID, outputs the startup command of the corresponding core processor, configures the initial instruction address of the core processor and the DDR address where the RTOS operating system is located.

[0018] Optionally, the step S3, after the heterogeneous operating system is loaded, generates an interrupt signal based on the inter-core interrupt and the corresponding register by the CLINT module in the master core, and implements data transfer between the master core and each of the slave cores based on the interrupt signal, including:

[0019] A CLINT module is configured in the master core, the CLINT module includes a global timer, the CLINT module is connected to each slave core, the CLINT module is configured with registers of the core processor of each slave core, and each register value is bound to the hart_id of the core processor;

[0020] Under the RISCV instruction architecture, the main core is switched to M mode through the actively initiated ebreak instruction;

[0021] Generate a register interrupt signal by timing the global timer of the CLINT module, and send the register interrupt signal to the core processor corresponding to the hart_id bound to the register;

[0022] When the core processor receives the register interrupt signal, it obtains the corresponding task data for processing and feeds back the processing result to the main core through the interrupt signal.

[0023] Optionally, under the RISCV instruction architecture, each core processor includes M mode, S mode and U mode.

[0024] Optionally, also include:

[0025] When the system is initialized, a shared memory is configured, and a shared memory area is allocated to each core processor. Each shared memory area has a unique identifier, and the unique identifier is bound to the hart_id of the core processor;

[0026] During the data sending phase, the master core writes the task data that needs to be transmitted to the core processor of the slave core into the shared memory area corresponding to the core processor;

[0027] The master core sends a register interrupt signal to the core processor of the slave core, and the core processor of the slave core receives the register interrupt signal, reads the task data from the shared memory area, copies the task data to the local memory, and processes the task data;

[0028] The core processor of the slave core returns the processing result of the task data to the master core.

[0029] The present invention provides a startup deployment and collaborative processing method for a multi-core heterogeneous system. When the system is running, the main core and each slave core simultaneously obtain the startup code, obtain the image files of the Linux operating system and the RTOS operating system respectively based on synchronous operation and storage partitioning, and run them on the main core and the slave core after moving; after the heterogeneous operating system is loaded, an interrupt signal is generated based on the inter-core interrupt and the corresponding register through the CLINT module in the main core, and the data communication between the main core and each slave core is realized based on the interrupt signal and shared memory. Through the method of the present invention, after the system is powered on, the multi-core can synchronously run the startup code, avoiding the time delay and uncertainty that may be caused by the startup of a single core one by one; communication and data transmission between the multi-cores are realized by means of interrupts and shared memory, ensuring the synchronization and consistency of the data, avoiding the wrong judgment and decision-making errors caused by data delays and inconsistencies, thereby significantly improving the real-time performance of the system. BRIEF DESCRIPTION OF THE DRAWINGS

[0030] Figure 1 A flowchart of a startup deployment and collaborative processing method for a multi-core heterogeneous system provided by the present invention;

[0031] Figure 2 A flowchart for deploying an operating system on a master core and a slave core;

[0032] Figure 3 A flowchart for configuring the heterogeneous operating system on the main core after loading;

[0033] Figure 4 Flowchart of data transfer between the master core and the slave core. DETAILED DESCRIPTION

[0034] In order to make the purpose, technical solutions and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments in the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention. In addition, the technical features in the various embodiments or single embodiments provided by the present invention can be arbitrarily combined with each other to form a feasible technical solution. This combination is not subject to the constraints of the sequence of steps and / or the structural composition mode, but must be based on the ability of ordinary technicians in this field to achieve. When the combination of technical solutions is contradictory or cannot be achieved, it should be considered that such a combination of technical solutions does not exist and is not within the scope of protection required by the present invention.

[0035] Based on the electroplating management strategy for multi-core processors in the background technology, taking into account the independence between multi-core processors and the real-time transmission of business interactions, by synchronously deploying the Linux+RTOS operating system in the multi-core processor, its startup and runtime space is isolated, and different operating systems can manage different memory and device resources during runtime, and the main core is initiated during business collaborative processing. On the other hand, the main design is oriented to multi-core processors with RISCV instruction set architecture, combining RISCV's exception instructions and interrupt handlers to achieve collaborative processing between multi-core processors. In response to the above needs, the present invention aims to provide a novel and efficient multi-core heterogeneous operating system design based on RSIC-V architecture to meet the complexity and high performance requirements of modern computing needs.

[0036] Figure 1 A flowchart of a startup deployment and collaborative processing method for a multi-core heterogeneous system provided by the present invention is shown in FIG. Figure 1 As shown, the method includes:

[0037] Step S1, after the system is powered on, multiple cores synchronously run the startup code, and cluster based on the hart_id of each core processor to determine a master core and multiple slave cores, wherein the master core and each slave core include multiple core processors.

[0038] It is understandable that in order to ensure that multi-core heterogeneous processors can run stably with each other, it is often necessary to synchronize the management of the entire hardware resources. Traditional heterogeneous solutions virtualize the system hardware resources to facilitate the deployment and solutions of multiple operating systems, but they consume software and hardware operating resources, which will sacrifice real-time performance. Therefore, the present invention can consider dividing them statically as much as possible during deployment, and synchronize the multi-core heterogeneous operating systems of the Linux operating system and the RTOS operating system on the multi-core processor to achieve independent management.

[0039] Specifically, for multi-core heterogeneous operating systems, every 4 small core processors belong to a cluster. The first cluster, mhardid, belongs to core processors 0 to 3 as the master core to load the Linux operating system, and the other clusters are slave cores to start the RTOS operating system. The master core and each slave core include multiple core processors.

[0040] Step S2, pre-store the operating system startup image file, determine the storage location of the heterogeneous operating system, the heterogeneous operating system includes the Linux operating system and the RTOS operating system, when the system is running, the main core and each slave core obtain the startup code after power-on, obtain the Linux operating system and the RTOS operating system from the storage location respectively, run the Linux operating system on the main core, and run the RTOS operating system on each slave core.

[0041] It is understandable that once the master core and slave core are determined, the master core is mainly responsible for comprehensive system management and computing task scheduling, while the slave core is mainly focused on receiving the task requirements of the master core and promptly feeding back the results to the master core after the task is completed.

[0042] Since the functions of the master core and the slave core are different, the present invention runs the Linux operating system in the master core and runs the RTOS operating system in each slave core. Figure 2 ,Deploying the operating system on the core processor includes: pre-storing the operating system startup image file, determining the storage location of the heterogeneous operating system, performing preliminary startup by the Linux operating system during runtime, and moving the saved RTOS operating system to the DDR, setting the clock and bus status of the core processor corresponding to hart_id, outputting the startup command of the corresponding core processor, configuring the initial instruction address of the core processor to be the same as the DDR address where the RTOS operating system is located, taking into account the different memory and peripheral resources set in the device tree of the Linux operating system and the configuration table of the RTOS operating system, and subsequently realizing the synchronous operation of the heterogeneous operating system on the corresponding core.

[0043] The process of deploying the Linux operating system and the RTOS operating system on the master core and slave core respectively includes:

[0044] S11, the image file copied from the Linux system, the ELF file compiled from the RTOS operating system, and the UBOOT boot tool used for system startup are burned into different sectors of the SD card after partitioning. Each sector has a unique identifier, and each sector stores different files.

[0045] S12, the boot code (UBOOT boot tool) is solidified in NandFlash. When the system is powered on, the main core directly reads the boot code from FLASH to SRAM1. The boot code includes DDR initialization, reading the UBOOT boot tool from the SD card to the DDR of each core processor and jumping to the UBOOT boot tool to start running.

[0046] S13, in the RISC-V instruction architecture, each core processor will record its own hart_id and keep it in the mhardid register. Therefore, although different core processors will run the boot code read from SRAM1 at the same time, based on different hart_ids, different core processors will read the files required by the corresponding operating system from different sectors of the SD card based on the UBOOT boot tool, thereby running the Linux operating system on the main core and the RTOS operating system on the slave core.

[0047] S14, during the UBOOT boot tool running phase, the master core and the slave core will read the Opensbi, Linux Image images, rtos elf files, device trees and file systems in different partitions of the SD card and load them into the corresponding memory addresses;

[0048] S15. During runtime, the Linux operating system performs preliminary startup and guides the saved RTOS operating system to be moved to the DDR of the core processor of the slave core, sets the clock and bus status of the core processor corresponding to hart_id, outputs the startup command of the corresponding core processor, configures the initial instruction address of the core processor and the DDR address where the RTOS operating system is located.

[0049] Step S3, after the heterogeneous operating system is loaded, an interrupt signal is generated by the CLINT module in the master core based on the inter-core interrupt and the corresponding register, and data communication between the master core and each of the slave cores is achieved based on the interrupt signal.

[0050] It is understandable that, through step S2, the Linux operating system is deployed in the master core, and the RTOS operating system is deployed in each slave core. After the heterogeneous operating system is loaded, it is necessary to implement real-time task scheduling and information transmission between multi-core processors. The present invention reads different hart_ids of multi-core processors based on RISCV instruction architecture, see Figure 3 In order to realize the data transmission between the master core and the slave core, some configuration work needs to be done in advance in the master core, including configuring the CLINT module in the master core, setting the interrupt number and register in the CLINT module, and establishing a system information table in the Linux operating system of the master core. The system information table stores the hart_id of each core processor and the task status of each core processor running.

[0051] The master core is responsible for system management and task scheduling, while the slave core executes tasks with high real-time requirements. The multi-core collaborative interrupt management mechanism of the interrupt processor based on the RISCV instruction architecture determines the task execution core by hart_id. The CLINT (Core Local Interrupt Controller) of the multi-core processor and the assigned inter-core interrupt (IPI) number are used to trigger the interrupt signal, and the divided shared memory is combined for data transmission. This solution determines the independence between cores to the greatest extent, which can reduce the overall load of the normal operation system and improve the real-time performance of synchronous processing in specific applications.

[0052] Methods for achieving communication between the master core and the slave core include:

[0053] S31, configuring a CLINT module in the master core, the CLINT module including a global timer, the CLINT module connected to each slave core, the CLINT module configured with registers of the core processor of each slave core, each register value being bound to the hart_id of the core processor;

[0054] S32, under the RISCV instruction architecture, switches the main core to M mode through the actively initiated ebreak instruction;

[0055] S33, generating a register interrupt signal by timing through the global timer of the CLINT module, and sending the register interrupt signal to the core processor corresponding to the hart_id bound to the register;

[0056] S34, when the core processor receives the register interrupt signal, it obtains the corresponding task data for processing, and feeds back the processing result to the main core through the interrupt signal.

[0057] It is understandable that after the multi-core heterogeneous operating system is loaded, the CLINT module is configured in the main core, and the CLINT module is connected to each core processor, and the hart_id of each core processor will determine the interrupt register value of the core processor in M ​​mode and S mode, and interrupt sending can be achieved by writing the value of the register. The CLINT module includes registers corresponding to each core processor, and the registers are bound to the hart_id of the core processor.

[0058] The CLINT module contains a global timer for generating timed interrupts, which is used for time management and task scheduling in multi-core heterogeneous operating systems, enabling each core processor to operate synchronously and coordinate work.

[0059] In the RISCV instruction architecture, the working modes of each core processor include M mode, S mode and U mode. The operating levels of multi-core interrupts in the CLINT module are only M mode and S mode. Usually, user-mode code runs in U mode.

[0060] If you want to achieve communication between the master core and the slave core through interrupts, you need to switch the working mode of the master core to M mode, and you need to use system calls and the M mode interface provided by Opensbi to access the inter-core interrupt. Specifically, for the RISCV architecture, through active system calls, you need to enter the exception handling process through an actively initiated ebreak instruction. The exception handling will actively switch the master core to M mode. In M mode, you can directly modify the registers of the CLINT module corresponding to the core processor to control the interrupt sending.

[0061] The CLINT module in the master core generates a register interrupt signal based on the global timer timing. Since each register is bound to the hart_id of the core processor of the slave core, the CLINT module sends the generated register interrupt signal to the core processor corresponding to the hart_id.

[0062] See also Figure 4 , when the master core passes the task data to the slave core for processing through the interrupt mechanism, it is realized by configuring the shared memory. Specifically, it includes:

[0063] S31', when the system is initialized, a shared memory is configured, and a shared memory area is allocated for each core processor. Each shared memory area has a unique identifier, and the unique identifier is bound to the hart_id of the core processor to ensure isolation and resource management between cores. The size of the shared memory area corresponding to different core processors can be allocated according to the processing capacity of the core processor.

[0064] S32', during the data sending phase, the master core writes the task data to be transmitted to the core processor of the slave core into the shared memory area corresponding to the core processor;

[0065] S33', the master core sends a register interrupt signal to the core processor of the slave core, and the core processor of the slave core receives the register interrupt signal, reads the task data from the shared memory area, copies the task data to the local memory, and processes the task data;

[0066] S34', the core processor of the slave core returns the processing result of the task data to the master core.

[0067] The present invention realizes data transfer between the master core and the slave core by configuring shared memory. The data transfer realized by the shared memory mode is non-blocking, which means that other tasks can be executed simultaneously between the multiple cores without being blocked by the data transfer operation. When the multi-core heterogeneous operating system is running, the allocation and release of the shared memory are automatically managed by the operating system kernel, which ensures the effective allocation of shared memory resources and prevents memory leakage.

[0068] The present invention respectively uses an embodiment to illustrate the deployment of heterogeneous operating systems, the communication between the master core and the slave core through an interrupt mechanism, and the data transfer between the master core and the slave core using a shared memory.

[0069] Exemplarily, the steps of deploying a heterogeneous operating system mainly include:

[0070] Step 11, the heterogeneous operating system is an organic combination of the Linux operating system and the RTOS operating system, which work together. This heterogeneous design is mainly aimed at scenarios with intensive computing requirements. The Linux operating system on the master core is responsible for comprehensive system management and computing task scheduling, while the RTOS operating system on the slave core focuses on receiving the task requirements of the master core and promptly feeding back the results to the master core after the task is completed. In this way, the heterogeneous design fully takes into account the advantages of real-time and efficient scheduling, and can ensure that the system responds quickly and executes efficiently when faced with complex computing tasks;

[0071] Step 12: The Image file required for starting the Linux operating system, the ELF file compiled by the RTOS operating system, and the UBOOT boot tool used to boot the operating system are all stored in different sectors of the SD card through precise burning operations. This storage method ensures that each system component can be accurately read and loaded during the startup process, providing a solid foundation for the stable startup of the system.

[0072] Step 13, the boot code is firmly fixed in NandFlash. When the system is powered on, the main core can quickly and accurately read the boot code from FLASH and load it into SRAM1 for execution. The boot code covers key steps such as DDR initialization, and also includes the function of reading the UBOOT boot tool from the SD card to the DDR of each core processor and smoothly jumping to the UBOOT boot tool for startup;

[0073] Step S14: In the RISCV instruction architecture, each core processor can accurately record its own hart_id and save it in the mhardid register. Therefore, although different core processors will run and read the boot code of SRAM1 at the same time, based on their different hart_ids, they will intelligently run to different core processors to achieve their own specific functions.

[0074] Step 15: For a multi-core heterogeneous operating system, every four small cores are planned as a cluster, wherein the first cluster, i.e., the core processors with mhardid 0 to 3, is set as the master core responsible for loading the Linux system, while the other clusters are slave cores responsible for starting the RTOS system;

[0075] Step 16. During the UBOOT operation phase, it will accurately read the Opensbi, Linux Image images, rtos elf files, device trees and file systems in different partitions of the SD card and load them into the corresponding memory addresses;

[0076] Step 17. Subsequently, the master core and the slave core respectively accurately load the corresponding Linux or RTOS system from the memory through the bootm command and the bootelf command in the UBOOT stage, thereby completing the startup process of the entire system.

[0077] Exemplarily, the steps of implementing communication between the master core and the slave core through an interrupt mechanism include:

[0078] Step 21, after the multi-core heterogeneous operating system is successfully loaded, the CLINT module in the master core is closely connected to each core processor of the slave core. At this time, the hart_id of each core processor will decisively affect the interrupt register value of the core processor in M ​​mode and S mode. By accurately writing the value of the register, efficient interrupt sending can be achieved;

[0079] Step 22: In the CLINT module, a crucial global timer is integrated, which is mainly used to generate timer interrupts. This function is crucial for time management and task scheduling of multi-core heterogeneous operating systems, and can ensure that each core can achieve synchronous operation and coordinated work;

[0080] Step 23. The RISC-V architecture covers three privilege levels: M mode, S mode, and U mode. In the operation level of multi-core interrupts, the CLINT module only involves M mode and S mode. Usually, user-mode code mainly runs in U mode. However, to access inter-core interrupts, you need to use system calls and the M-mode interface provided by Opensbi;

[0081] Step 24. According to the characteristics of the RICSV architecture, a specific ebreak instruction needs to be initiated through an active system call to enter the exception handling process. During this process, the exception handling will actively switch the main core to M mode. In M mode, the registers of the core processor corresponding to the CLINT module can be directly modified, thereby accurately controlling the interrupt sending.

[0082] The use of shared memory to realize data transfer between the master core and the slave core mainly includes:

[0083] Step 31, during the critical phase of system initialization, carefully allocate dedicated shared memory regions for each core processor, each with a unique identifier and a carefully set size, to ensure effective isolation and precise resource management between cores;

[0084] Step 32: During the system initialization process, a dedicated shared memory region is continuously allocated to each core processor, each shared memory region has a unique identifier and an appropriate size, thereby effectively ensuring isolation between cores and accuracy of resource management;

[0085] Step 33, at the critical stage of data transmission, the master core first accurately writes the data to be transmitted into its dedicated shared memory area, and then the master core sends an interrupt signal to the slave core to clearly indicate that the data is ready to be received. After receiving the interrupt, the receiving core (slave core) will quickly read the shared memory area corresponding to the slave core and accurately copy the data to the local memory for subsequent efficient processing;

[0086] Step 34: Data transfer implemented by shared memory has a non-blocking characteristic, which means that the cores can execute other tasks simultaneously without being affected by the blocking of the data transfer operation;

[0087] Step 35: During the operation of the multi-core heterogeneous operating system, the allocation and release of shared memory are automatically managed by the operating system kernel. This mechanism effectively ensures the effective allocation of shared memory resources and can effectively prevent the occurrence of memory leaks.

[0088] The invention provides a startup deployment and collaborative processing method for a multi-core heterogeneous system, which has the following beneficial effects:

[0089] (1) The synchronous startup mode is adopted. After the system is powered on, multiple cores can run the startup code synchronously. In this way, the time delay and uncertainty caused by starting a single core one by one are avoided. In this process, multiple cores are clustered according to hard_id, and the storage location of the master core, slave core and heterogeneous operating system is quickly identified. With the help of different startup methods of UBOOT, synchronous startup is achieved. In the application scenario of large-scale data processing, this fast synchronous startup can make the system enter the working state immediately, respond to the needs of processing tasks in time, and greatly reduce the preparation time of the system. At the same time, due to the consistency and stability of synchronous startup, the errors and anomalies caused by asynchronous startup are reduced, and the reliability of long-term operation of the system is enhanced.

[0090] (2) The master core shoulders the key responsibilities of system management and task scheduling, including peripheral management, task resource allocation, etc., while the slave core focuses on receiving the task requirements of the master core and executing the tasks efficiently. Taking complex image processing tasks as an example, the master core can scientifically and reasonably allocate tasks to different slave cores according to the complexity of the image and the processing requirements. The slave core then quickly runs the specific image processing algorithm, greatly improving the system's resource utilization and task execution efficiency.

[0091] (3) Interrupts and shared memory are used to achieve communication and data transfer between multiple cores. After the multi-core heterogeneous operating system is loaded, the sending and receiving of interrupts are achieved with the help of the CLINT interrupt controller used for inter-core interrupts. In the data transfer process, a dedicated shared memory area is configured for each core. When an interrupt is issued, the receiver will read the shared memory area to obtain the task requirements, ensuring the synchronization and consistency of the data, avoiding misjudgments and decision-making errors caused by data delays and inconsistencies, and significantly improving the real-time performance of the system.

[0092] (4) With a clear startup process and clear division of labor in the master-slave core architecture, when problems occur during system operation, by monitoring the task allocation of the master and slave cores and the usage of shared memory, the core or data interaction link that may have problems can be quickly identified, and targeted repairs and adjustments can be made, greatly reducing maintenance costs and time.

[0093] (5) Through the optimized configuration of multi-core resources and efficient collaborative operations, in step S1, the synchronous startup method and reasonable core cluster division enable the system to quickly enter the working state and fully exert the parallel processing capabilities of multi-cores. In step S2, the flexible interrupt management implemented by the CLINT interrupt controller ensures the timely scheduling and switching of tasks and avoids the idleness and waste of core resources. In step S3, the shared memory interaction method achieves efficient data transmission and reduces the time overhead of data transmission between different cores. In the field of high-performance computing, facing large-scale numerical simulation and computing tasks, this system can quickly complete complex calculations and meet the stringent requirements of modern computing needs for complexity and high performance.

[0094] It should be noted that in the above embodiments, the description of each embodiment has its own emphasis, and for parts that are not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0095] Those skilled in the art will appreciate that embodiments of the present invention may be provided as methods, systems, or computer program products. Therefore, the present invention may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, the present invention may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0096] The present invention is described with reference to flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded computer, or other programmable data processing device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0097] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0098] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0099] Although the preferred embodiments of the present invention have been described, those skilled in the art may make other changes and modifications to these embodiments once they have learned the basic creative concept. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and all changes and modifications that fall within the scope of the present invention.

[0100] Obviously, those skilled in the art can make various changes and modifications to the present invention without departing from the spirit and scope of the present invention. Thus, if these modifications and variations of the present invention fall within the scope of the claims of the present invention and their equivalents, the present invention is also intended to include these modifications and variations.

Claims

1. A startup deployment and collaborative processing method for a multi-core heterogeneous system, characterized in that: include: Step S1, after the system is powered on, multiple cores synchronously run the startup code, and cluster based on the hart_id of each core processor to determine a master core and multiple slave cores, wherein the master core and each slave core include multiple core processors to form a corresponding cluster; Step S2, pre-store the operating system boot image file, determine the storage location of the heterogeneous operating system, the heterogeneous operating system includes the Linux operating system and the RTOS operating system, when the system is running, the master core and each slave core obtain the boot code after powering on, obtain the Linux operating system and the RTOS operating system from the storage location respectively, run the Linux operating system on the master core, and run the RTOS operating system on each slave core; Step S3, after the heterogeneous operating system is loaded, an interrupt signal is generated by the CLINT module in the master core based on the inter-core interrupt and the corresponding register, and data communication between the master core and each of the slave cores is achieved based on the interrupt signal.

2. The startup deployment and collaborative processing method for multi-core heterogeneous systems according to claim 1, characterized in that: In step S1, after the system is powered on, the multi-cores synchronously run the startup code, and clustering is performed based on the hart_id of each core processor to determine the master core and multiple slave cores, including: All core processors are clustered in a manner that every 4 core processors form a cluster, the first cluster being the master core and the other clusters being slave cores.

3. The startup deployment and collaborative processing method for multi-core heterogeneous systems according to claim 1, characterized in that: In step S2, when the system is running, the master core and each slave core simultaneously obtain the startup code, obtain the Linux operating system and the RTOS operating system from the storage location respectively, run the Linux operating system on the master core, and run the RTOS operating system on each slave core, including: Burn the Image file copied from the Linux operating system, the EIF file compiled from the RTOS operating system, and the UBOOT boot tool used for system startup into different sectors of the partitioned SD card; When the system is powered on, the main core reads the boot code from FLASH into SRAM1. The boot code includes DDR initialization of each core processor, reading the UBOOT boot tool from the sector of the SD card into DDR, and jumping to the UBOOT boot tool to start; In the RISC-V architecture, the master core and each slave core simultaneously read the boot code in SRAM1, and read the Linux operating system or RTOS operating system from different sectors of the SD card. Based on the UBOOT boot tool, the Linux operating system runs on the master core and the RTOS operating system runs on each slave core.

4. The startup deployment and collaborative processing method for multi-core heterogeneous systems according to claim 3, characterized in that: During the UBOOT boot tool running phase, the Opensbi in different sectors of the SD card, the Image image file of the Linux operating system, the ELF file of the RTOS operating system, the device tree and the file system are read and loaded into the corresponding memory address; During runtime, the Linux operating system performs the initial startup. At the same time, the UBOOT boot tool guides the saved RTOS operating system to the DDR of each slave core, sets the clock and bus status of the core processor corresponding to the HART_ID, outputs the startup command of the corresponding core processor, configures the initial instruction address of the core processor and the DDR address where the RTOS operating system is located.

5. The startup deployment and collaborative processing method for multi-core heterogeneous systems according to claim 1, characterized in that: The step S3, after the heterogeneous operating system is loaded, generates an interrupt signal based on the inter-core interrupt and the corresponding register through the CLINT module in the master core, and implements data communication between the master core and each of the slave cores based on the interrupt signal, including: A CLINT module is configured in the master core, the CLINT module includes a global timer, the CLINT module is connected to each slave core, the CLINT module is configured with registers of the core processor of each slave core, and each register value is bound to the hart_id of the core processor; Under the RISCV instruction architecture, the main core is switched to M mode through the actively initiated ebreak instruction; Generate a register interrupt signal by timing the global timer of the CLINT module, and send the register interrupt signal to the core processor corresponding to the hart_id bound to the register; When the core processor receives the register interrupt signal, it obtains the corresponding task data for processing and feeds back the processing result to the main core through the interrupt signal.

6. The startup deployment and collaborative processing method for multi-core heterogeneous systems according to claim 5, characterized in that: Under the RISCV instruction architecture, each core processor includes M mode, S mode and U mode.

7. The startup deployment and collaborative processing method for multi-core heterogeneous systems according to claim 5, characterized in that: Also includes: When the system is initialized, a shared memory is configured, and a shared memory area is allocated to each core processor. Each shared memory area has a unique identifier, and the unique identifier is bound to the hart_id of the core processor; During the data sending phase, the master core writes the task data that needs to be transmitted to the core processor of the slave core into the shared memory area corresponding to the core processor; The master core sends a register interrupt signal to the core processor of the slave core, and the core processor of the slave core receives the register interrupt signal, reads the task data from the shared memory area, copies the task data to the local memory, and processes the task data; The core processor of the slave core returns the processing result of the task data to the master core.

Images