System starting method and device, storage medium, electronic equipment and computer program product

Abstract

The embodiment of the invention provides a system starting method and device, a storage medium, electronic equipment and a computer program product, and the method comprises the steps that a read-only memory corresponding to each central processing unit in a target system is started, and the target system is a multi-path RISC-V system; under the condition that the read-only memory is successfully started, loading a boot loader through the read-only memory corresponding to each path of central processing unit, and fusing the boot loader loaded by each read-only memory; under the condition that the boot loader loaded by each read-only memory is successfully fused, a plurality of processor cores of each central processing unit are controlled to execute opensbi firmware of the target system; and under the condition that the plurality of processor cores of each path of central processing unit successfully execute the opensbi firmware of the target system, controlling the plurality of processor cores of each path of central processing unit to start the kernel of the target system so as to start the target system.

Description

Technical Field

[0001] The embodiments of the present application relate to the field of computers, and more specifically, to a system startup method and device, a storage medium, an electronic device, and a computer program product. Background Art

[0002] In today's era of ever-expanding Internet, people's demand for access to websites has also shown a spurt of growth. However, a single server is often difficult to handle a large number of users accessing at the same time, causing site downtime. In order to achieve high availability of websites, multi-way servers are widely used. Multi-way servers are multiple servers that are combined together to provide services to users by sharing traffic or tasks. This method can not only increase the access speed of the website, but also improve the stability and security of the network.

[0003] As a new processor, the fifth generation Reduced Instruction Set Computer V (RISC-V) has also experienced the development from single-core to multi-core to multi-channel with the improvement of RISC-V technology. The system process of a single central processing unit (CPU) is bootrom->u-boot->opensbi->kernel. However, the relevant technology does not involve the solution of multi-channel RISC-V system startup.

[0004] With regard to the related technologies, no effective solution has been proposed yet that does not involve the problem of multi-channel RISC-V system startup.

[0005] Therefore, it is necessary to improve the related technology to overcome the above-mentioned defects in the related technology. Summary of the invention

[0006] The embodiments of the present application provide a system startup method and device, a storage medium, an electronic device, and a computer program product to at least solve the problem that the related art does not involve a solution for starting a multi-path RISC-V system.

[0007] According to one embodiment of the present application, a system startup method is provided, comprising: starting a read-only memory corresponding to each central processing unit in a target system, wherein the target system is a multi-channel RISC-V system; when the read-only memory is successfully started, loading a boot loader through the read-only memory corresponding to each central processing unit, and fusing the boot loader loaded by each read-only memory; when the boot loader loaded by each read-only memory is successfully fused, controlling multiple processor cores of each central processing unit to execute opensbi firmware of the target system; when the multiple processor cores of each central processing unit successfully execute the opensbi firmware of the target system, controlling the multiple processor cores of each central processing unit to start the kernel of the target system to start the target system.

[0008] In an exemplary embodiment, after loading the boot loader program through the read-only memory corresponding to each central processor, the method further includes: determining a master boot core and a slave core corresponding to each central processor, wherein the multiple processor cores of each central processor include: the master boot core and the slave core; and copying the boot loader program to a dynamic random access memory through the master boot core, so that the master boot core runs the boot loader program through the dynamic random access memory.

[0009] In an exemplary embodiment, copying the boot loader to a dynamic random access memory through the main boot core so that the main boot core runs the boot loader through the dynamic random access memory includes: running the boot loader through the main boot core so that the main boot core performs a peripheral initialization operation, a self-copy operation, a relocation operation, and a CCIX initialization operation through the boot loader.

[0010] In an exemplary embodiment, determining the main startup core and the slave core corresponding to each central processing unit includes: determining the runtime of each processor core in each central processing unit running a target program; determining the processor core with the shortest runtime as the main startup core, and determining the other processor cores as the slave cores.

[0011] In an exemplary embodiment, the boot loader programs loaded by each read-only memory are merged, including: configuring a cache consistency protocol for a multi-way central processing unit through target software; and determining to merge the boot loader programs loaded by the read-only memories corresponding to the multi-way central processing units when the target software successfully configures the cache consistency protocol for the multi-way central processing units.

[0012] In an exemplary embodiment, controlling the multiple processor cores of each central processing unit to execute the opensbi firmware of the target system includes: determining the master boot core and the slave core corresponding to each central processing unit, wherein the multiple processor cores of each central processing unit include: the master boot core and the slave core; controlling the master boot core of each central processing unit to execute the opensbi firmware of the target system; and controlling the slave core of each central processing unit to execute the opensbi firmware of the target system when the master boot core of each central processing unit successfully executes the opensbi firmware of the target system.

[0013] In an exemplary embodiment, controlling the slave core of each central processor to execute the opensbi firmware of the target system includes: waking up the slave core of each central processor through the master boot core of each central processor so that the slave core of each central processor executes the opensbi firmware of the target system.

[0014] In an exemplary embodiment, controlling the multiple processor cores of each central processing unit to execute the opensbi firmware of the target system includes: obtaining a device tree of the target system; creating temporary resources for the multiple processor cores of each central processing unit through the device tree, wherein the temporary resources include at least one of the following: a platform-level interrupt controller, a timer interrupt controller, and a core local interrupt controller; and establishing a connection relationship between the multiple processors of each central processing unit and the temporary resources through a target bus.

[0015] In an exemplary embodiment, obtaining the device tree of the target system includes: defining corresponding attribute information and nodes for each processor core of each central processor in the device tree, wherein the attribute information includes: an identifier of the processor core and a memory address range of the processor core; determining temporary resources that each processor core is allowed to access, and storing the correspondence between each processor core and the corresponding temporary resources in a node of the device tree.

[0016] In an exemplary embodiment, controlling the multiple processor cores of each central processing unit to start the kernel of the target system includes: determining a master boot core and a slave core corresponding to each central processing unit, wherein the multiple processor cores of each central processing unit include: the master boot core and the slave core; controlling the master boot core of each central processing unit to start the kernel of the target system; and controlling the slave core of each central processing unit to start the kernel of the target system when the master boot core of each central processing unit successfully starts the kernel of the target system.

[0017] In an exemplary embodiment, controlling the slave core of each central processor to start the kernel of the target system includes: waking up the slave core of each central processor by the master boot core of each central processor so that the slave core of each central processor starts the kernel of the target system.

[0018] According to another embodiment of the present application, a system startup device is provided, including: a startup module, used to start the read-only memory corresponding to each central processing unit in the target system, wherein the target system is a multi-channel RISC-V system; a loading module, used to load a boot loader through the read-only memory corresponding to each central processing unit when the read-only memory is successfully started, and merge the boot loader loaded by each read-only memory; a first control module, used to control the multiple processor cores of each central processing unit to execute the opensbi firmware of the target system when the boot loader loaded by each read-only memory is successfully merged; a second control module, used to control the multiple processor cores of each central processing unit to start the kernel of the target system to start the target system when the multiple processor cores of each central processing unit successfully execute the opensbi firmware of the target system.

[0019] According to another embodiment of the present application, a computer-readable storage medium is provided, in which a computer program is stored, wherein the computer program is configured to execute the steps of any of the above method embodiments when run.

[0020] According to another embodiment of the present application, an electronic device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to execute the steps in any one of the above method embodiments.

[0021] According to another embodiment of the present application, a computer program product is provided, including a computer program, and when the computer program is executed by a processor, the steps in any of the above method embodiments are implemented.

[0022] Through the embodiment of the present application, the read-only memory corresponding to each central processor in the target system is started, wherein the target system is a multi-channel RISC-V system; when the read-only memory is successfully started, the boot loader is loaded through the read-only memory corresponding to each central processor, and the boot loader loaded by each read-only memory is merged; when the boot loader loaded by each read-only memory is successfully merged, the multiple processor cores of each central processor are controlled to execute the opensbi firmware of the target system; when the multiple processor cores of each central processor successfully execute the opensbi firmware of the target system, the multiple processor cores of each central processor are controlled to start the kernel of the target system to start the target system. That is, in the present application, the read-only memory is started, the boot loader is loaded, the boot loader is merged, the opensbi firmware of the target system is executed, and the kernel of the target system is started to complete the startup of the target system, which solves the problem of the scheme that does not involve the startup of the multi-channel RISC-V system in the related art, and then completes the startup of the target system. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The exemplary embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0024] Figure 1 It is a hardware structure block diagram of a computer device of a system startup method of an embodiment of the present application;

[0025] Figure 2 is a flowchart of a method for starting a system according to an embodiment of the present application;

[0026] Figure 3 is a schematic diagram of a 2-way CPU according to an optional embodiment of the present application;

[0027] Figure 4 is a schematic diagram of a parallel node according to an optional embodiment of the present application;

[0028] Figure 5 is a flow chart of a RISC-V based multi-way system according to an optional embodiment of the present application;

[0029] Figure 6 It is a structural block diagram of a starting device of a system according to an embodiment of the present application. DETAILED DESCRIPTION

[0030] The embodiments of the present application will be described in detail below with reference to the accompanying drawings and in combination with the embodiments.

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

[0032] In this embodiment, a method for starting a system is also provided. The method embodiment provided in the embodiment of the present application can be executed in a starting device of the system. The starting device of the system can be a computer device or a similar computing device. Taking running on a computer device as an example, Figure 1 1 is a hardware structure block diagram of a computer device for a method of starting a system according to an embodiment of the present application. Figure 1 As shown, the computer device may include one or more ( Figure 1 Only one is shown in the figure) a processor 102 (the processor 102 may include but is not limited to a processing device such as a microprocessor MCU or a programmable logic device FPGA) and a memory 104 for storing data, wherein the above-mentioned computer device may also include a transmission device 106 and an input and output device 108 for communication functions. It can be understood by those skilled in the art that Figure 1 The structure shown is only for illustration and does not limit the structure of the above-mentioned computer device. Figure 1 More or fewer components as shown, or with Figure 1 Different configurations shown.

[0033] The memory 104 can be used to store computer programs, for example, software programs and modules of application software, such as the computer program corresponding to the startup method of the system in the embodiment of the present application. The processor 102 executes various functional applications and data processing by running the computer program stored in the memory 104, that is, to implement the above method. The memory 104 may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some examples, the memory 104 may further include a memory remotely arranged relative to the processor 102, and these remote memories may be connected to the computer device via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0034] The transmission device 106 is used to receive or send data via a network. The specific example of the above network may include a wireless network provided by a communication provider of the computer device. In one example, the transmission device 106 includes a network adapter (Network Interface Controller, referred to as NIC), which can be connected to other network devices through a base station so as to communicate with the Internet. In one example, the transmission device 106 can be a radio frequency (RF) module, which is used to communicate with the Internet wirelessly.

[0035] In this embodiment, a method for starting a system is provided. Figure 2 is a flowchart of a method for starting a system according to an embodiment of the present application. Figure 2 As shown, the process includes the following steps:

[0036] Step S202, starting the read-only memory corresponding to each central processing unit in the target system, wherein the target system is a multi-channel RISC-V system;

[0037] It should be noted that the above-mentioned read-only memory may be Bootrom, wherein Bootrom loads and executes a boot program. Bootrom is a solid-state memory in a computer system, which usually contains the most basic firmware and boot program for starting the computer system. When the computer is turned on, Bootrom will first be loaded into the memory and the boot program therein will be executed to start the operating system or other necessary programs.

[0038] Step S204, when the read-only memory is successfully started, loading a boot loader program through the read-only memory corresponding to each central processing unit, and integrating the boot loader programs loaded by each read-only memory;

[0039] It should be noted that the above-mentioned boot loader program may be a u-boot program.

[0040] Step S206, when the boot loader loaded by each read-only memory is successfully integrated, controlling the multiple processor cores of each central processing unit to execute the opensbi firmware of the target system;

[0041] Step S208, when the multiple processor cores of each central processing unit successfully execute the opensbi firmware of the target system, control the multiple processor cores of each central processing unit to start the kernel of the target system to start the target system.

[0042] It should be noted that the above-mentioned kernel can be understood as kernel.

[0043] Through the above steps, through the embodiment of the present application, the read-only memory corresponding to each central processor in the target system is started, wherein the target system is a multi-channel RISC-V system; when the read-only memory is successfully started, the boot loader is loaded through the read-only memory corresponding to each central processor, and the boot loader loaded by each read-only memory is merged; when the boot loader loaded by each read-only memory is successfully merged, the multiple processor cores of each central processor are controlled to execute the opensbi firmware of the target system; when the multiple processor cores of each central processor successfully execute the opensbi firmware of the target system, the multiple processor cores of each central processor are controlled to start the kernel of the target system to start the target system. That is, in the present application, the read-only memory is started, the boot loader is loaded, the boot loader is merged, the opensbi firmware of the target system is executed, and the kernel of the target system is started to complete the startup of the target system, which solves the problem of the scheme that does not involve the startup of multi-channel RISC-V systems in the related art.

[0044] Optionally, after loading the boot loader program through the read-only memory corresponding to each central processing unit, the following steps need to be performed: determining the master boot core and the slave core corresponding to each central processing unit, wherein the multiple processor cores of each central processing unit include: the master boot core and the slave core; copying the boot loader program to the dynamic random access memory through the master boot core, so that the master boot core runs the boot loader program through the dynamic random access memory.

[0045] In an embodiment of the present application, after loading the boot loader, it is also necessary to use the master boot core in each CPU to copy the u-boot program to the dynamic random access memory DDR, and then the master boot core and the slave core jump the boot process to the u-boot program to run.

[0046] Optionally, in the process of running the u-boot program, the following is also included: running the boot loader through the main boot core, so that the main boot core performs peripheral initialization operations, self-copy operations, relocation operations, and cache consistency protocol (Cache Coherent Interconnect for Accelerators, abbreviated as CCIX) initialization operations through the boot loader.

[0047] That is, when the u-boot program is loaded, each CPU selects the main boot core to perform uboot startup to perform necessary peripheral initialization, self-copying, relocation, CCIX initialization, etc., and the remaining slave cores enter the state of waiting for interruption, waiting to be awakened by the main boot core.

[0048] It should be noted that running the u-boot program can initialize hardware devices and drivers, providing users with a friendly command line interface to facilitate system configuration and management. At the same time, u-boot can also implement network boot, firmware upgrade, memory test and other functions.

[0049] In an exemplary embodiment, determining the main startup core and the slave core corresponding to each central processing unit includes: determining the runtime of each processor core in each central processing unit running a target program; determining the processor core with the shortest runtime as the main startup core, and determining the other processor cores as the slave cores.

[0050] In an embodiment of the present application, a method for determining a main startup core and a slave core is provided, that is, the main startup core and the slave core are determined according to the running time of each processor core running a target program, the processor core with the shortest running time is determined as the main startup core, and the other processor cores are determined as slave cores.

[0051] It should be noted that, when one or more processor cores are determined as slave cores, the slave cores enter a state of waiting for interruption, waiting to be awakened by the master startup core.

[0052] When multiple processor cores are divided into master boot cores and slave cores, they play a complementary role in the multi-core processor system, improving the overall performance and parallel processing capabilities of the system. The master boot core is responsible for the overall scheduling and control of the system, providing higher performance and responsiveness; while the slave core is responsible for processing specific tasks and calculations, improving the parallel processing efficiency and resource utilization of the system. By properly configuring and utilizing the master boot core and slave core, the potential of the multi-core processor system can be fully utilized to improve the performance and efficiency of the system.

[0053] Optionally, the boot loader programs loaded into each read-only memory are merged, including: configuring a cache consistency protocol for a multi-way central processing unit through target software; and when the target software successfully configures the cache consistency protocol for the multi-way central processing unit, determining that the boot loader programs loaded into the read-only memories corresponding to the multi-way central processing units are merged.

[0054] In the embodiment of the present application, the cache consistency protocol CCIX is configured for the multi-way central processing units, so that the boot loader programs loaded into the read-only memories corresponding to the multi-way central processing units are determined to be merged.

[0055] It should be noted that when multiple CPUs share a common memory space, they can improve performance by communicating the cached and / or cacheable states of each part of the memory. In this way, each RISC-V core can safely process a portion of the common data set. After CCIX initialization is completed, the address space configuration is completed, and multiple channels can access each other, that is, multiple CPUs share a common memory space. When the fusion is completed, the multi-channel CPU can be regarded as a single multi-core CPU. Here, the hartid of each core is required to be different to facilitate the execution of internal interrupts. After the main startup core wakes up from the core, all cores jump to opensbi together.

[0056] Optionally, controlling the multiple processor cores of each central processing unit to execute the opensbi firmware of the target system includes: determining the master boot core and the slave core corresponding to each central processing unit, wherein the multiple processor cores of each central processing unit include: the master boot core and the slave core; controlling the master boot core of each central processing unit to execute the opensbi firmware of the target system; when the master boot core of each central processing unit successfully executes the opensbi firmware of the target system, controlling the slave core of each central processing unit to execute the opensbi firmware of the target system.

[0057] Optionally, controlling the slave core of each central processor to execute the opensbi firmware of the target system includes: waking up the slave core of each central processor through the master boot core of each central processor, so that the slave core of each central processor executes the opensbi firmware of the target system.

[0058] In the embodiment of the present application, SBI runs directly in the system machine mode with the highest authority, can access all hardware resources, and provides a unified system call environment to the operating system. The operating system enters the machine mode through special instructions and executes the callback function of SBI. In opensbi, one core is selected as the main startup core, and all other cores are slave cores. The slave core is in the wait for interrupt (WFI) state. When the main startup core executes the opensbi firmware of the target system, the main startup core wakes up the slave core so that the slave core executes the opensbi firmware of the target system.

[0059] In an exemplary embodiment, controlling the multiple processor cores of each central processing unit to execute the opensbi firmware of the target system includes: obtaining a device tree of the target system; creating temporary resources for the multiple processor cores of each central processing unit through the device tree, wherein the temporary resources include at least one of the following: a platform-level interrupt controller, a timer interrupt controller, and a core local interrupt controller; and establishing a connection relationship between the multiple processors of each central processing unit and the temporary resources through a target bus.

[0060] In the embodiment of the present application, multiple CPUs use the device tree to distinguish between sockets and harts, and create scratch resources for the processor cores. Multiple cores interact with each other through interrupts, and use the device tree to configure resources such as the plic platform-level interrupt controller, the timer interrupt controller, and the core local interrupt controller (Core Local Interruptor, referred to as CLINT), where the processor core is connected to the configured resources through the bus.

[0061] Among them, CLINT is an interrupt controller in the RISC-V architecture, which is used to handle interrupt events local to the processor core. CLINT is usually used inside the processor core to manage and handle interrupt requests and interrupt processing related to the core. It can coordinate the interrupt processing flow inside the processor core to ensure that interrupts can be responded to and processed in a timely manner. CLINT can also communicate with other external interrupt controllers or global interrupt controllers to coordinate the distribution and processing of interrupts in the entire system.

[0062] In an exemplary embodiment, obtaining the device tree of the target system includes: defining corresponding attribute information and nodes for each processor core of each central processor in the device tree, wherein the attribute information includes: an identifier of the processor core and a memory address range of the processor core; determining temporary resources that each processor core is allowed to access, and storing the correspondence between each processor core and the corresponding temporary resources in a node of the device tree.

[0063] Specifically: The steps to create scratch resources for the processor core are as follows:

[0064] 1. Define corresponding attributes and nodes for each processor core (bootserver processor (BSP) and application processor (AP)) in the device tree, including information such as processor identification and memory address range.

[0065] 2. Use the properties and node relationships in the device tree to specify which processor cores can access and use specific scratch resources.

[0066] 3. When the operating system starts, it parses the device tree, reads the information in it and configures the corresponding scratch resources to ensure that each processor core can correctly access and use these resources.

[0067] In an embodiment of the present application, creating scratch resources for BSP and AP through a device tree can help the operating system correctly configure and manage resources in a multi-way CPU system, thereby coordinating communication and collaboration between processor cores and improving system performance and reliability.

[0068] In an exemplary embodiment, controlling the multiple processor cores of each central processing unit to start the kernel of the target system includes: determining a master boot core and a slave core corresponding to each central processing unit, wherein the multiple processor cores of each central processing unit include: the master boot core and the slave core; controlling the master boot core of each central processing unit to start the kernel of the target system; and controlling the slave core of each central processing unit to start the kernel of the target system when the master boot core of each central processing unit successfully starts the kernel of the target system.

[0069] In an exemplary embodiment, controlling the slave core of each central processor to start the kernel of the target system includes: waking up the slave core of each central processor by the master boot core of each central processor so that the slave core of each central processor starts the kernel of the target system.

[0070] In the embodiment of the present application, when the master boot core starts the kernel of the target system, the master boot core wakes up the slave core so that the slave core starts the kernel of the target system. It should be noted that the master boot core jumps from machine mode to supervisor mode, that is, jumps from opensbi to kernel, and the slave core waits for wakeup. After the master boot core wakes up the slave core, the slave core jumps from opensbi to kernel to complete the startup of the multi-way RISC-V kernel.

[0071] Obviously, the above-described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. In order to better understand the startup method of the above-mentioned system, the above-mentioned process is described below in conjunction with the embodiments, but it is not intended to limit the technical solutions of the embodiments of the present application, specifically:

[0072] With the development of CPU technology, the demand for CPU is getting higher and higher. A CPU is composed of multiple cores, and multiple CPUs are composed of multi-way CPUs. Multiple cores are distinguished by hartid, and multiple routes are distinguished by socketid. Figure 3 As shown in the figure, CPU0 consists of two cores, which is a dual-core CPU. Multi-core CPUs share information through L2. CPU0 and CPU1 form a dual-core CPU. Information between the two CPUs is shared through CCIX.

[0073] In the embodiment of the present application, a method for starting a system is also provided, such as Figure 5 As shown, Figure 5 This is a flowchart of a method for starting a system according to an optional embodiment of the present application, and the specific steps are as follows:

[0074] Step 1: Power on;

[0075] Step 2: bootrom loads u-boot;

[0076] After the CPU is powered on, each CPU will automatically jump to the bootrom. Each CPU will select a core as the main boot core BSP, and the other cores as slave cores AP. Each CPU uses BSP to copy the u-boot program to DDR, and BSP / AP will jump the startup process to u-boot operation.

[0077] Step 3: u-boot initialization;

[0078] Each CPU selects BSP to start uboot and perform necessary peripheral initialization, self-copying, relocation, CCIX initialization, etc. The remaining AP cores enter the WFI state and wait for the BSP to wake up.

[0079] Step 4: u-boot fusion;

[0080] When multiple CPUs share a common memory space, they can improve performance by communicating the cached and / or cacheable states of each part of the memory. In this way, each RISC-V core can safely process a portion of the common data set. CCIX is a cache consistency protocol. After CCIX initialization is completed, the address space configuration is completed, and multiple channels can access each other. When the fusion is completed, the multi-channel CPU can be regarded as a single multi-core CPU. Here, each core is required to have a different hartid to facilitate the execution of internal interrupts. After the BSP wakes up the AP, all cores jump to opensbi together.

[0081] Step 5: U-boot jumps to opensbi, opensbi executes;

[0082] SBI is (RISC-V Supervisor Binary Interface). SBI runs directly in the system machine mode and has the highest authority. It can access all hardware resources and provide a unified system call environment to the operating system. The operating system enters the machine mode through special instructions and executes the SBI callback function. In opensbi, one core is selected as the BSP, and all other cores are in AP state. AP is in WFI state. Multi-channel CPUs use device tree to distinguish sockets and harts, and create scratch resources for BSP / AP. Multi-cores interact with each other through interrupts. Use devicetree to configure plic platform-level interrupt controllers, timer interrupt controllers, clint processor core local interrupt processors and other resources, which are connected through the bus, such as Figure 4 shown.

[0083] Step 6: BPS jumps from opensbi to kernel;

[0084] Step 7: BPS wakes up AP, and AP jumps from opensbi to kernel;

[0085] Step 8: Kernel starts.

[0086] BSP jumps from machine mode to supervisor mode, that is, jumps from opensbi to kernel, and AP waits to be awakened. After BSP wakes up AP, AP jumps from opensbi to kernel to complete the startup of multi-path RISC-V kernel.

[0087] In an embodiment of the present application, a multi-way system startup method based on RISC-V is proposed. With the development of CPU technology and the improvement of RISC-V technology, the demand for multi-way RISC-V system startup is becoming increasingly obvious. During the multi-way RISC-V system startup, starting the system according to this process can ensure that the system starts normally, the multi-way RISC-V works normally, and the multi-way RISC-V system is successfully started.

[0088] Through the description of the above implementation methods, those skilled in the art can clearly understand that the method according to the above embodiment can be implemented by means of software plus a necessary general hardware platform, and of course by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk), and includes a number of instructions for a terminal device (which can be a mobile phone, computer, server, or network device, etc.) to execute the methods described in each embodiment of the present application.

[0089] In this embodiment, a system startup device is also provided, which is used to implement the above-mentioned embodiments and preferred implementation modes, and the descriptions that have been made will not be repeated. As used below, the term "module" can implement a combination of software and / or hardware of a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, the implementation of hardware, or a combination of software and hardware, is also possible and conceivable.

[0090] Figure 6 is a structural block diagram of a starting device of a system according to an embodiment of the present application, such as Figure 6 As shown, the device comprises:

[0091] A startup module 62, used to start the read-only memory corresponding to each central processing unit in the target system, wherein the target system is a multi-channel RISC-V system;

[0092] A loading module 64, configured to load a boot loader program through the read-only memory corresponding to each central processing unit when the read-only memory is successfully started, and merge the boot loader programs loaded by each read-only memory;

[0093] A first control module 66 is used to control the multiple processor cores of each central processor to execute the opensbi firmware of the target system when the boot loader loaded by each read-only memory is successfully integrated;

[0094] The second control module 68 is used to control the multiple processor cores of each central processing unit to start the kernel of the target system to start the target system when the multiple processor cores of each central processing unit successfully execute the opensbi firmware of the target system.

[0095] Through the device of the present application, through the embodiment of the present application, the read-only memory corresponding to each central processor in the target system is started, wherein the target system is a multi-channel RISC-V system; when the read-only memory is successfully started, the boot loader is loaded through the read-only memory corresponding to each central processor, and the boot loader loaded by each read-only memory is merged; when the boot loader loaded by each read-only memory is successfully merged, the multiple processor cores of each central processor are controlled to execute the opensbi firmware of the target system; when the multiple processor cores of each central processor successfully execute the opensbi firmware of the target system, the multiple processor cores of each central processor are controlled to start the kernel of the target system to start the target system. That is, in the present application, the read-only memory is started, the boot loader is loaded, the boot loader is merged, the opensbi firmware of the target system is executed, and the kernel of the target system is started to complete the startup of the target system, which solves the problem of the scheme that does not involve the startup of multi-channel RISC-V systems in the related art.

[0096] In an exemplary embodiment, the loading module 64 is used to determine the main boot core and the slave core corresponding to each central processing unit, wherein the multiple processor cores of each central processing unit include: the main boot core and the slave core; the boot loader is copied to the dynamic random access memory through the main boot core, so that the main boot core runs the boot loader through the dynamic random access memory.

[0097] In an exemplary embodiment, the loading module 64 is used to run the boot loader through the main boot core, so that the main boot core performs peripheral initialization operation, self-copy operation, relocation operation, and CCIX initialization operation through the boot loader.

[0098] That is, when the u-boot program is loaded, each CPU selects the main boot core to perform uboot startup to perform necessary peripheral initialization, self-copying, relocation, CCIX initialization, etc., and the remaining slave cores enter the state of waiting for interruption, waiting to be awakened by the main boot core.

[0099] It should be noted that running the u-boot program can initialize hardware devices and drivers, providing users with a friendly command line interface to facilitate system configuration and management. At the same time, u-boot can also implement network boot, firmware upgrade, memory test and other functions.

[0100] In an exemplary embodiment, the loading module 64 is used to determine the runtime of each processor core in each central processor running the target program; determine the processor core with the shortest runtime as the main startup core, and determine the other processor cores as the slave cores.

[0101] It should be noted that, when one or more processor cores are determined as slave cores, the slave cores enter a state of waiting for interruption, waiting to be awakened by the master startup core.

[0102] When multiple processor cores are divided into master boot cores and slave cores, they play a complementary role in the multi-core processor system, improving the overall performance and parallel processing capabilities of the system. The master boot core is responsible for the overall scheduling and control of the system, providing higher performance and responsiveness; while the slave core is responsible for processing specific tasks and calculations, improving the parallel processing efficiency and resource utilization of the system. By properly configuring and utilizing the master boot core and slave core, the potential of the multi-core processor system can be fully utilized to improve the performance and efficiency of the system.

[0103] In an exemplary embodiment, the loading module 64 is used to configure a cache consistency protocol for a multi-way central processing unit through target software; when the target software successfully configures the cache consistency protocol for the multi-way central processing unit, determine to merge the boot loader loaded from the read-only memory corresponding to the multi-way central processing unit.

[0104] In the embodiment of the present application, the cache consistency protocol CCIX is configured for the multi-way central processing units, so that the boot loader programs loaded into the read-only memories corresponding to the multi-way central processing units are determined to be merged.

[0105] It should be noted that when multiple CPUs share a common memory space, they can improve performance by communicating the cached and / or cacheable states of each part of the memory. In this way, each RISC-V core can safely process a portion of the common data set. After CCIX initialization is completed, the address space configuration is completed, and multiple channels can access each other, that is, multiple CPUs share a common memory space. When the fusion is completed, the multi-channel CPU can be regarded as a single multi-core CPU. Here, the hartid of each core is required to be different to facilitate the execution of internal interrupts. After the main startup core wakes up from the core, all cores jump to opensbi together.

[0106] In an exemplary embodiment, the first control module 66 is used to determine the master boot core and the slave core corresponding to each central processor, wherein the multiple processor cores of each central processor include: the master boot core and the slave core; control the master boot core of each central processor to execute the opensbi firmware of the target system; when the master boot core of each central processor successfully executes the opensbi firmware of the target system, control the slave core of each central processor to execute the opensbi firmware of the target system.

[0107] In an exemplary embodiment, the first control module 66 is used to wake up the slave core of each central processor through the master boot core of each central processor, so that the slave core of each central processor executes the opensbi firmware of the target system.

[0108] In the embodiment of the present application, SBI runs directly in the system machine mode with the highest authority, can access all hardware resources, and provides a unified system call environment to the operating system. The operating system enters the machine mode through special instructions and executes the callback function of SBI. In opensbi, one core is selected as the main startup core, and all other cores are in the slave core, and the slave core is in the WFI state. When the main startup core executes the opensbi firmware of the target system, the main startup core wakes up the slave core so that the slave core executes the opensbi firmware of the target system.

[0109] In an exemplary embodiment, the first control module 66 is used to obtain the device tree of the target system; create temporary resources for the multiple processor cores of each central processing unit through the device tree, wherein the temporary resources include at least one of the following: a platform-level interrupt controller, a timer interrupt controller, and a core local interrupt controller; and establish a connection relationship between the multiple processors of each central processing unit and the temporary resources through a target bus.

[0110] In the embodiment of the present application, multiple CPUs use the device tree to distinguish between sockets and harts, and create scratch resources for the processor cores. Multiple cores interact with each other through interrupts, and use the device tree to configure resources such as the plic platform-level interrupt controller, the timer interrupt controller, and the core local interrupt controller (Core Local Interruptor, referred to as CLINT), where the processor core is connected to the configured resources through the bus.

[0111] Among them, CLINT is an interrupt controller in the RISC-V architecture, which is used to handle interrupt events local to the processor core. CLINT is usually used inside the processor core to manage and handle interrupt requests and interrupt processing related to the core. It can coordinate the interrupt processing flow inside the processor core to ensure that interrupts can be responded to and processed in a timely manner. CLINT can also communicate with other external interrupt controllers or global interrupt controllers to coordinate the distribution and processing of interrupts in the entire system.

[0112] In an exemplary embodiment, the first control module 66 is used to define corresponding attribute information and nodes for each processor core of each central processor in the device tree, wherein the attribute information includes: an identifier of the processor core, a memory address range of the processor core; determining temporary resources that each processor core is allowed to access, and storing the correspondence between each processor core and the corresponding temporary resources in the node of the device tree.

[0113] Specifically: The steps to create scratch resources for the processor core are as follows:

[0114] 1. Define corresponding properties and nodes for each processor core (BSP and AP) in the device tree, including information such as processor identification and memory address range.

[0115] 2. Use the properties and node relationships in the device tree to specify which processor cores can access and use specific scratch resources.

[0116] 3. When the operating system starts, it parses the device tree, reads the information in it and configures the corresponding scratch resources to ensure that each processor core can correctly access and use these resources.

[0117] In an embodiment of the present application, creating scratch resources for BSP and AP through a device tree can help the operating system correctly configure and manage resources in a multi-way CPU system, thereby coordinating communication and collaboration between processor cores and improving system performance and reliability.

[0118] In an exemplary embodiment, the second control module 68 is used to determine the master boot core and the slave core corresponding to each central processing unit, wherein the multiple processor cores of each central processing unit include: the master boot core and the slave core; control the master boot core of each central processing unit to start the kernel of the target system; and control the slave core of each central processing unit to start the kernel of the target system when the master boot core of each central processing unit successfully starts the kernel of the target system.

[0119] In an exemplary embodiment, the second control module 68 is used to wake up the slave core of each central processor through the master boot core of each central processor, so that the slave core of each central processor starts the kernel of the target system.

[0120] In the embodiment of the present application, when the master boot core starts the kernel of the target system, the master boot core wakes up the slave core so that the slave core starts the kernel of the target system. It should be noted that the master boot core jumps from machine mode to supervisor mode, that is, jumps from opensbi to kernel, and the slave core waits for wakeup. After the master boot core wakes up the slave core, the slave core jumps from opensbi to kernel to complete the startup of the multi-way RISC-V kernel.

[0121] An embodiment of the present application further provides a computer-readable storage medium, in which a computer program is stored, wherein the computer program is configured to execute the steps of any of the above method embodiments when running.

[0122] Optionally, in this embodiment, the storage medium may be configured to store a computer program for performing the following steps:

[0123] S1, starting the read-only memory corresponding to each central processing unit in the target system, wherein the target system is a multi-channel RISC-V system;

[0124] S2, when the read-only memory is successfully started, loading a boot loader program through the read-only memory corresponding to each central processing unit, and integrating the boot loader programs loaded by each read-only memory;

[0125] S3, when the boot loader loaded by each read-only memory is successfully integrated, controlling the multiple processor cores of each central processing unit to execute the opensbi firmware of the target system;

[0126] S4, when the multiple processor cores of each central processing unit successfully execute the opensbi firmware of the target system, control the multiple processor cores of each central processing unit to start the kernel of the target system to start the target system.

[0127] In an exemplary embodiment, the computer-readable storage medium may include, but is not limited to, various media that can store computer programs, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk or an optical disk.

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

[0129] Optionally, in this embodiment, the processor may be configured to perform the following steps through a computer program:

[0130] S1, starting the read-only memory corresponding to each central processing unit in the target system, wherein the target system is a multi-channel RISC-V system;

[0131] S2, when the read-only memory is successfully started, loading a boot loader program through the read-only memory corresponding to each central processing unit, and integrating the boot loader programs loaded by each read-only memory;

[0132] S3, when the boot loader loaded by each read-only memory is successfully integrated, controlling the multiple processor cores of each central processing unit to execute the opensbi firmware of the target system;

[0133] S4, when the multiple processor cores of each central processing unit successfully execute the opensbi firmware of the target system, control the multiple processor cores of each central processing unit to start the kernel of the target system to start the target system.

[0134] In an exemplary embodiment, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor, and the input / output device is connected to the processor.

[0135] An embodiment of the present application further provides a computer program product, which includes a computer program. When the computer program is executed by a processor, the steps in any one of the above method embodiments are implemented.

[0136] Optionally, in this embodiment, the computer program product may be configured to perform the following steps through a computer program:

[0137] S1, starting the read-only memory corresponding to each central processing unit in the target system, wherein the target system is a multi-channel RISC-V system;

[0138] S2, when the read-only memory is successfully started, loading a boot loader program through the read-only memory corresponding to each central processing unit, and integrating the boot loader programs loaded by each read-only memory;

[0139] S3, when the boot loader loaded by each read-only memory is successfully integrated, controlling the multiple processor cores of each central processing unit to execute the opensbi firmware of the target system;

[0140] S4, when the multiple processor cores of each central processing unit successfully execute the opensbi firmware of the target system, control the multiple processor cores of each central processing unit to start the kernel of the target system to start the target system.

[0141] An embodiment of the present application further provides another computer program product, including a non-volatile computer-readable storage medium, wherein the non-volatile computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps in any of the above method embodiments are implemented.

[0142] The embodiments of the present application also provide a computer program, which includes computer instructions, which are stored in a computer-readable storage medium; a processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device executes the steps in any one of the above method embodiments.

[0143] For specific examples in this embodiment, reference may be made to the examples described in the above embodiments and exemplary implementation modes, and this embodiment will not be described in detail herein.

[0144] Obviously, those skilled in the art should understand that the above modules or steps of the present application can be implemented by a general computing device, they can be concentrated on a single computing device, or distributed on a network composed of multiple computing devices, they can be implemented by a program code executable by a computing device, so that they can be stored in a storage device and executed by the computing device, and in some cases, the steps shown or described can be executed in a different order from that herein, or they can be made into individual integrated circuit modules, or multiple modules or steps therein can be made into a single integrated circuit module for implementation. Thus, the present application is not limited to any specific combination of hardware and software.

[0145] The above description is only the preferred embodiment of the present application and is not intended to limit the present application. For those skilled in the art, the present application may have various modifications and variations. Any modification, equivalent replacement, improvement, etc. made within the principles of the present application shall be included in the protection scope of the present application.

Claims

1. A method for starting a system, characterized in that: include: Starting the read-only memory corresponding to each central processing unit in the target system, wherein the target system is a multi-channel RISC-V system; In the case where the read-only memory is successfully started, loading a boot loader program through the read-only memory corresponding to each central processing unit, and merging the boot loader programs loaded by each read-only memory; When the boot loader loaded by each read-only memory is successfully integrated, the multiple processor cores of each central processing unit are controlled to execute the opensbi firmware of the target system; In the case where the multiple processor cores of each central processing unit successfully execute the opensbi firmware of the target system, the multiple processor cores of each central processing unit are controlled to start the kernel of the target system to start the target system.

2. The method according to claim 1, characterized in that After loading the boot loader program through the read-only memory corresponding to each central processing unit, the method further includes: Determine the master boot core and the slave core corresponding to each central processing unit, wherein the multiple processor cores of each central processing unit include: the master boot core and the slave core; The boot loader is copied to a dynamic random access memory by the main boot core, so that the main boot core runs the boot loader through the dynamic random access memory.

3. The method according to claim 2, characterized in that The method comprises: copying the boot loader program to a dynamic random access memory through the main boot core so that the main boot core runs the boot loader program through the dynamic random access memory, comprising: The boot loader is run through the main boot core, so that the main boot core performs peripheral initialization operation, self-copy operation, relocation operation, and CCIX initialization operation through the boot loader.

4. The method according to claim 2, characterized in that: Determining the master startup core and slave core corresponding to each central processing unit includes: Determining the running time of each processor core in each central processing unit to run the target program; The processor core with the shortest running time is determined as the main startup core, and the other processor cores are determined as the slave cores.

5. The method according to claim 1, characterized in that Merge the bootloader loaded from each ROM, including: Configure cache coherence protocols for multi-way CPUs through target software; In the case where the target software successfully configures the cache consistency protocol for the multi-way central processing unit, it is determined that the boot loader programs loaded by the read-only memories corresponding to the multi-way central processing unit are merged.

6. The method according to claim 1, characterized in that Controlling the multiple processor cores of each central processor to execute the opensbi firmware of the target system includes: Determine the master boot core and the slave core corresponding to each central processing unit, wherein the multiple processor cores of each central processing unit include: the master boot core and the slave core; Control the main boot core of each central processing unit to execute the opensbi firmware of the target system; When the main boot core of each central processing unit successfully executes the opensbi firmware of the target system, the slave core of each central processing unit is controlled to execute the opensbi firmware of the target system.

7. The method according to claim 6, characterized in that Controlling the slave core of each central processing unit to execute the opensbi firmware of the target system includes: The slave core of each central processor is awakened by the master boot core of each central processor, so that the slave core of each central processor executes the opensbi firmware of the target system.

8. The method according to claim 1, characterized in that Controlling the multiple processor cores of each central processor to execute the opensbi firmware of the target system includes: Obtaining a device tree of the target system; Creating temporary resources for the multiple processor cores of each central processor through the device tree, wherein the temporary resources include at least one of the following: a platform-level interrupt controller, a timer interrupt controller, and a core local interrupt controller; A connection relationship between the multiple processors of each central processing unit and the temporary resources is established through the target bus.

9. The method according to claim 8, characterized in that Get the device tree of the target system, including: In the device tree, corresponding attribute information and nodes are defined for each processor core of each central processor, wherein the attribute information includes: an identifier of the processor core and a memory address range of the processor core; Determine the temporary resources that each processor core is allowed to access, and store the corresponding relationship between each processor core and the corresponding temporary resource in the node of the device tree.

10. The method according to claim 1, characterized in that Controlling the multiple processor cores of each central processing unit to start the kernel of the target system includes: Determine the master boot core and the slave core corresponding to each central processing unit, wherein the multiple processor cores of each central processing unit include: the master boot core and the slave core; Control the main startup core of each central processing unit to start the kernel of the target system; When the master boot core of each central processing unit successfully boots the kernel of the target system, the slave core of each central processing unit is controlled to boot the kernel of the target system.

11. The method according to claim 10, characterized in that Controlling the slave core of each central processing unit to start the kernel of the target system includes: The slave core of each central processor is awakened by the master startup core of each central processor, so that the slave core of each central processor starts the kernel of the target system.

12. A system starting device, characterized in that: include: A startup module, used to start the read-only memory corresponding to each central processing unit in the target system, wherein the target system is a multi-channel RISC-V system; A loading module, used for loading a boot loader program through the read-only memory corresponding to each central processing unit when the read-only memory is successfully started, and fusing the boot loader programs loaded by each read-only memory; A first control module is used to control the multiple processor cores of each central processing unit to execute the opensbi firmware of the target system when the boot loader loaded by each read-only memory is successfully integrated; The second control module is used to control the multiple processor cores of each central processing unit to start the kernel of the target system to start the target system when the multiple processor cores of each central processing unit successfully execute the opensbi firmware of the target system.

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

14. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 11 are implemented.

15. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 11 are implemented.

Images