A startup deployment and collaborative processing method for multi-core heterogeneous systems

Abstract

The present invention provides a startup deployment and collaborative processing method for a multi-core heterogeneous system. When the system is running, the master core and slave core obtain startup code after powering on. Based on synchronous operation and storage partitioning, the Linux and RTOS image files are respectively obtained, and after being moved, they are run on the master core and slave core. After the heterogeneous operating system is loaded, the CLINT module in the master core generates an interrupt signal based on inter-core interrupts and corresponding registers. Data communication between the master core and each slave core is achieved based on the interrupt signal and shared memory. With the method of the present invention, after the system is powered on, the multi-cores can synchronously run the startup code, avoiding the time delay and uncertainty that may be caused by starting a single core one by one. Communication and data transfer between the multi-cores are achieved through interrupts and shared memory, ensuring data synchronization and consistency, avoiding misjudgments and decision errors caused by data delays and inconsistencies, and thus significantly improving the real-time performance of the system.

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 mainstream in modern computers and embedded systems, integrating multiple processor cores onto a single chip to improve processing power and efficiency. Multi-core processors play a vital role in a variety of applications, including high-performance computing, servers, mobile devices, and embedded systems. To ensure reliability, real-time performance, and longevity during extended operation, multi-core processors assign high-load tasks to the master core, while slave cores perform basic tasks. This involves complex scheduling, requiring the operating system to collaboratively and efficiently manage resource scheduling, task allocation, and communication among multiple cores.

[0003] Considering that operating system management and deployment for multi-core heterogeneous processors involves complex hardware initialization, operating system loading, and multi-core collaboration, this brings many challenges. Existing boot methods use virtualized scheduling management strategies, which consume a large amount 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 and management strategies 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 perform clustering based on the hart_id of each core processor to determine a master core and multiple slave cores. The master core and each slave core include multiple core processors to form corresponding clusters.

[0007] Step S2: pre-store an operating system boot image file, determine the storage location of a heterogeneous operating system, wherein the heterogeneous operating system includes a Linux operating system and an RTOS operating system. When the system is running, the master core and each slave core obtain 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] On the basis of 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 perform clustering 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 four 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 SD card sector 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 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 addresses;

[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, 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. Each register value is bound to the hart_id of the core processor.

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

[0021] Generate a register interrupt signal regularly through 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 for each core processor. Each shared memory area has a unique identifier, which 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. 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 master core and each slave core simultaneously obtain startup code, obtain the image files of the Linux operating system and the RTOS operating system respectively based on synchronous operation and storage partitioning, move them and run them on the master core and the slave core; after the heterogeneous operating system is loaded, the CLINT module in the master core generates an interrupt signal based on inter-core interrupts and corresponding registers, and realizes data communication between the master core and each slave core based on the interrupt signal and shared memory. With the method of the present invention, after the system is powered on, the multi-cores can synchronously run the startup code, avoiding the time delay and uncertainty that may be caused by the startup of each single core one by one; communication and data transfer between the multi-cores are realized by means of interrupts and shared memory, ensuring the synchronization and consistency of data, avoiding misjudgments and decision errors caused by data delays and inconsistencies, and thus 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 multi-core heterogeneous systems provided by the present invention;

[0031] Figure 2 Flowchart for deploying the operating system on the master core and the slave core;

[0032] Figure 3 This is 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 of the present invention, all other embodiments obtained by ordinary technicians in this field without making 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 restricted by the sequence of steps and / or structural composition mode, but must be based on the ability of ordinary technicians in this field to implement it. When the combination of technical solutions is contradictory or cannot be implemented, it should be deemed 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 are isolated, and different operating systems can manage different memory and device resources during runtime. The main core is initiated when the business is collaboratively processed. On the other hand, the main design is oriented to the multi-core processor with RISCV instruction set architecture, combining the exception instructions and interrupt handlers of RISCV to realize 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 scheme based on RISC-V architecture to meet the complexity and high performance requirements of modern computing needs.

[0036] Figure 1 The present invention provides a method for starting up, deploying and coordinating multi-core heterogeneous systems. Figure 1 As shown, the method includes:

[0037] Step S1: After the system is powered on, multiple cores synchronously run the startup code and perform clustering 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 stable operation of multi-core heterogeneous processors, it is often necessary to synchronize and manage all hardware resources. Traditional heterogeneous solutions virtualize system hardware resources to facilitate the deployment and deployment of multiple operating systems, but this consumes software and hardware operating resources, resulting in a sacrifice in real-time performance. Therefore, the present invention can consider static partitioning as much as possible during deployment, synchronously deploying the multi-core heterogeneous operating systems of the Linux operating system and RTOS operating system on the multi-core processor to achieve independent management.

[0039] Specifically, for a multi-core heterogeneous operating system, each of four small core processors belongs to a cluster. The first cluster, or mhardid, contains core processors 0 through 3, which serves as the master core and loads the Linux operating system. The other clusters serve as slave cores and start the RTOS operating system. The master core and each slave core contain 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 powering 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 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 boot image file, determining the storage location of the ,heterogeneous operating system, performing the initial boot by the Linux operating system at ,runtime, and at the same time, moving the saved RTOS operating system to the DDR, setting the clock and bus states of the ,core processor corresponding to hart_id, outputting the boot command for the ,core processor, configuring the initial instruction address of the core processor to 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 implementing the synchronous running of the heterogeneous operating system on the ,corresponding cores.

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

[0044] S11, the Linux system is copied into the image file, the ELF file compiled by the RTOS operating system, and the UBOOT boot tool used for system startup are burned into different sectors of the partitioned SD card. Each sector has a unique identifier and 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 into SRAM1. The boot code includes DDR initialization, reading the UBOOT boot tool from the SD card into 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 use the UBOOT boot tool and read the files required by the corresponding operating system from different sectors of the SD card to run, thereby running the Linux operating system on the master 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 from different partitions in 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, after the Linux operating system is deployed in the master core and the RTOS operating system is deployed in each slave core through step S2, it is necessary to implement real-time task scheduling and information transmission between multi-core processors after the heterogeneous operating systems are loaded. 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 cores execute tasks requiring high real-time performance. The multi-core collaborative interrupt management mechanism based on the interrupt processor of the RISC-V instruction architecture uses the hart_id to determine the core executing a task. This scheme utilizes the multi-core processor's CLINT (Core Local Interrupt Controller) and the assigned inter-core interrupt (IPI) number to trigger interrupt signals, combined with partitioned shared memory for data transfer. This solution maximizes inter-core independence, reducing the overall system load during normal operation and improving 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, and each register value 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 the global timer of the CLINT module at a fixed time, 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's understandable that after a multi-core heterogeneous operating system is loaded, the CLINT module is configured in the master core and connected to each core processor. Each core processor's hart_id determines the interrupt register value for that core processor in M ​​and S modes. Writing to this register value enables interrupt transmission. The CLINT module includes registers corresponding to each core processor, which are bound to the core processor's hart_id.

[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 RISC-V instruction architecture, the operating 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] To enable communication between the master and slave cores via interrupts, the master core must be switched to M-mode. Inter-core interrupts can only be accessed through system calls and the M-mode interface provided by Opensbi. Specifically, for the RISC-V architecture, an active system call requires an ebreak instruction to enter the exception handling process. This will automatically switch the master core to M-mode. In M-mode, the CLINT module's corresponding core processor registers can be directly modified to control interrupt transmission.

[0061] The CLINT module in the master core generates a register interrupt signal based on the global timer. 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 task data to the slave core for processing through the interrupt mechanism, this is achieved by configuring shared memory. Specifically, it includes:

[0063] During system initialization, a shared memory block is configured and a shared memory region is allocated for each core processor. Each shared memory region has a unique identifier, which is bound to the core processor's hart_id to ensure isolation and resource management between cores. The size of the shared memory region corresponding to each core processor can be allocated based on the core processor's processing power.

[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. 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 implements data transfer between the master and slave cores by configuring shared memory. This non-blocking shared memory approach allows multiple cores to simultaneously execute other tasks without being blocked by data transfers. During the operation of a multi-core heterogeneous operating system, the allocation and release of shared memory is automatically managed by the operating system kernel, ensuring efficient allocation of shared memory resources and preventing memory leaks.

[0068] The present invention uses an embodiment to illustrate the deployment of heterogeneous operating systems, the communication between the master core and the slave cores through the interrupt mechanism, and the data transfer between the master core and the slave cores using 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, working 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 is focused on receiving task requirements from the master core and promptly feeding back the results to the master core after the task is completed. In this way, this heterogeneous design fully takes into account the advantages of real-time performance and efficient scheduling, ensuring that the system responds quickly and executes efficiently when faced with complex computing tasks.

[0071] Step 12: The Image file required for booting 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 boot process, providing a solid foundation for stable system startup;

[0072] Step 13. The boot code is firmly stored 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, as well as reading the UBOOT boot tool from the SD card into the DDR of each core processor and smoothly jumping to the UBOOT boot tool for startup.

[0073] Step S14: In the RISC-V 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 specific functions.

[0074] Step 15: For a multi-core heterogeneous operating system, every four small cores are planned as a cluster. The first cluster, i.e., the core processors with mhardids 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 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 the 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 this register, efficient interrupt sending can be achieved.

[0079] Step 22. A crucial global timer is integrated into the CLINT module. It is mainly used to generate timer interrupts. This function is crucial for time management and task scheduling in multi-core heterogeneous operating systems, ensuring that each core can operate synchronously and coordinate work.

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

[0081] Step 24. Due 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 CLINT module corresponding to the core processor can be directly modified to accurately control interrupt sending.

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

[0083] Step 31: During the critical phase of system initialization, a dedicated shared memory region is carefully allocated for each core processor. Each shared memory region has a unique identifier and a carefully defined 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 accurate resource management.

[0085] Step 33: During the critical data transmission phase, the master core first accurately writes the data to be transmitted into its dedicated shared memory area. Subsequently, the master core sends an interrupt signal to the slave core, clearly indicating that the data is ready to be received. After receiving the interrupt, the receiving core (slave core) quickly reads the corresponding shared memory area of ​​the slave core and accurately copies the data into local memory for subsequent efficient processing.

[0086] Step 34: Data transfer via shared memory is non-blocking, meaning that cores can execute other tasks simultaneously without being blocked by 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 present invention provides a startup deployment and collaborative processing method for multi-core heterogeneous systems, which has the following beneficial effects:

[0089] (1) Using the synchronous startup mode, 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 each 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 determined. Synchronous startup is achieved with the help of different startup methods of UBOOT. In the application scenario of large-scale data processing, this fast synchronous startup can enable the system to enter the working state immediately, respond to the needs of processing tasks in a timely manner, 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 the 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 and task resource allocation, 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 rationally allocate tasks to different slave cores according to the complexity and processing requirements of the image. 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 CLINT interrupt controller used for inter-core interrupts is used to achieve the sending and receiving of interrupts. During 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 thus significantly improving the real-time performance of the system.

[0092] (4) With a clear startup process and a 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 where the problem may occur can be quickly identified, and then 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 the multi-core. In step S2, the flexible interrupt management implemented by the CLINT interrupt controller ensures the timely scheduling and switching of tasks, avoiding 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 focus. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant description of other embodiments.

[0095] It will be understood by those skilled in the art that embodiments of the present invention may be provided as methods, systems, or computer program products. Thus, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware. Furthermore, 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 magnetic 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 flowcharts and / or block diagrams, as well as combinations of processes and / or blocks in the flowcharts and / or block diagrams, 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 produce 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 flowcharts and / or block diagrams. 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 that can direct a computer or other programmable data processing device to work 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 The 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 operational steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing the instructions executed on the computer or other programmable device for implementing the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0099] Although the preferred embodiments of the present invention have been described, those skilled in the art may make additional 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 may make various changes and modifications to the present invention without departing from the spirit and scope of the present invention. Thus, if such changes and modifications fall within the scope of the claims and their equivalents, the present invention is intended to include such changes and modifications.

Claims

1. A startup deployment and collaborative processing method for multi-core heterogeneous systems, characterized in that: include: Step S1: After the system is powered on, multiple cores synchronously run the startup code and perform clustering based on the hart_id of each core processor to determine a master core and multiple slave cores. The master core and each slave core include multiple core processors to form corresponding clusters. Step S2: pre-store an operating system boot image file, determine the storage location of a heterogeneous operating system, wherein the heterogeneous operating system includes a Linux operating system and an RTOS operating system. When the system is running, the master core and each slave core obtain 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-core processors synchronously run the startup code and perform clustering 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 four 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 SD card sector 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 operation phase, the Opensbi of different sectors in the SD card, the 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 by 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. Each register value is bound to the hart_id of the core processor. In the RISCV instruction architecture, the main core is switched to M mode through the actively initiated ebreak instruction; Generate a register interrupt signal regularly through 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 RISC-V 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 for each core processor. Each shared memory area has a unique identifier, which 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. 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