A new LinuxBoot booting method and system based on a RISC-V server CPU

Abstract

The application relates to a novel LinuxBoot starting and booting method and system based on a RISC-V server CPU, which comprises the following steps: firstly, ZSBL is executed, and FSBL is loaded and jumped to. Then, the FSBL loads a DTB, OpenSBI and LinuxBoot into a memory; the OpenSBI firstly executes underlying initialization, then executes platform early initialization, related hardware device initialization and platform final initialization, and finally executes secondary boot to jump to a LinuxBoot kernel; the LinuxBoot kernel loads u-root as initramfs; the LinuxBoot kernel loads a real Linux kernel image and a device tree, and sets hardware configuration and parameters, so that the Linux kernel is started. The application improves the efficiency and flexibility of system starting; and realizes fast, reliable and flexible starting of a server system.

Description

Technical Field

[0001] This invention relates to the field of computers, and in particular to a novel Linux Boot method for booting a system based on a RISC-V server CPU. Background Technology

[0002] UEFI is a firmware interface standard that replaces the traditional BIOS (Basic Input / Output System) for initializing hardware and booting the operating system. UEFI provides a scalable firmware environment with greater functionality and flexibility. It supports the loading and execution of multiple operating systems, drivers, and applications. The UEFI bootloader is responsible for initializing system hardware, loading the operating system image and device drivers, and initiating the execution of the operating system.

[0003] LinuxBoot is an open-source project designed to replace traditional firmware (such as BIOS and UEFI) with the Linux kernel as the system bootloader. It uses the Linux kernel as the boot environment, achieving faster, more reliable, and more flexible system startup by loading the Linux kernel and user-space toolset during the boot process. LinuxBoot provides a lightweight and highly flexible boot solution by simplifying the boot process and reducing complex boot layers.

[0004] In modern computer systems, the boot process is one of the key steps in starting the operating system. Traditional boot processes rely on complex boot layers and traditional BIOS / UEFI, which can introduce additional complexity and instability in some cases. With the increasing adoption of RISC-V architecture in the server field, the need for a faster, more reliable, and more flexible Linux Boot method is becoming increasingly urgent. Summary of the Invention

[0005] To address the limitations of existing boot processes that rely on complex boot layers and traditional BIOS / UEFI, and to meet the demands of RISC-V server CPU applications, this invention provides a novel Linux boot method based on a RISC-V server CPU. This method simplifies the boot process and reduces reliance on traditional BIOS / UEFI, achieving faster, more reliable, and more flexible Linux kernel booting.

[0006] The present invention also provides a novel Linux Boot system based on a RISC-V server CPU.

[0007] Terminology Explanation:

[0008] 1. RISC-V: RISC-V is an open-source instruction set architecture that employs a reduced instruction set architecture, modular design, and scalability. This makes RISC-V processors simple to design, low in cost, and flexibly expandable as needed. RISC-V offers cross-platform support, is widely used in various fields, and continues to develop within an open ecosystem.

[0009] 2. OpenSBI: OpenSBI is an open-source, standardized hypervisor binary interface designed to simplify the development and porting of RISC-V system software, providing a common foundation, standardized interfaces, and scalability to promote the development and innovation of the RISC-V ecosystem.

[0010] 3. EXT4 File System: The EXT4 file system is a high-performance, highly reliable Linux file system that meets the needs of modern computing environments by increasing file system capacity, improving performance, and introducing more powerful features.

[0011] 4. EXT4 File System Driver: The EXT4 file system driver is a module in the Linux operating system used to interact with and manage the EXT4 file system. It provides functions for creating, reading, writing, deleting, and modifying files, directories, and file attributes, and provides consistency protection and disk space management.

[0012] 5. Hart (Hardware Thread): In RISC-V, a Hart refers to a processor core that executes a stream of instructions. Each Hart has a unique identifier called the Hart ID. Initializing a Hart involves setting its initial state, configuring registers, and initiating instruction execution.

[0013] 6. Console: The console is the system's standard input / output device, used for user interaction and displaying debugging information. Initializing the console involves configuring the input and output interfaces, and ensuring the correct input and output channels.

[0014] 7. PMU (Performance Monitoring Unit): The PMU is a hardware component used to monitor and record system performance data, such as instruction execution count and cache hit rate. Initializing the PMU involves configuring counters and event selection for performance analysis and optimization.

[0015] 8. IRQ (Interrupt Request): An IRQ is an interrupt request used to notify the processor that an external event has occurred, such as a device input or clock interrupt. Initializing an IRQ involves configuring the interrupt controller and interrupt handlers to ensure that the system can respond to and process interrupt requests in a timely manner.

[0016] 9. IPI (Inter-Processor Interrupt): IPI refers to inter-processor interrupts used for communication and cooperation between processors. Initializing IPI involves configuring the IPI controller and the interrupt handlers to achieve synchronization and data sharing between processors.

[0017] 10. TLB (Translation Lookaside Buffer): A TLB is a hardware cache used to store the translation mapping from virtual addresses to physical addresses. Initializing a TLB involves configuring and populating TLB entries to ensure correct address translation and memory access permissions.

[0018] 11. Timer: A timer is a timer device in the system used to provide a time base and timing functions. Initializing a timer involves configuring the timer's frequency and mode, as well as setting up interrupts to implement timer interrupt functionality.

[0019] 12. ecall (Environment Call, System Call): ecall is a special machine instruction used to request services from the operating system from a user-mode program. Initializing ecall involves setting up the ecall handler and system call interface so that user programs can interact with the operating system through ecall instructions.

[0020] 13. Domain: A domain refers to a processor's privilege level and permission domain, used to isolate and protect different software entities. Initializing a domain involves configuring the processor's privilege level and permission mode to ensure proper permission switching and access control.

[0021] 14. PMP (Physical Memory Protection): PMP is a hardware mechanism used to protect access permissions to physical memory. Initializing PMP involves setting PMP registers and rules to ensure proper protection and access restrictions for memory regions.

[0022] 15. Platform Final Initialization: This refers to the final initialization step performed after the hardware initialization is complete. This may involve initializing other platform-specific devices, configuring system boot options, loading the operating system or applications, etc.

[0023] The technical solution adopted in this invention is as follows:

[0024] A novel Linux Boot method based on a RISC-V server CPU includes:

[0025] After the server CPU is powered on, ZSBL is executed first. ZSBL is responsible for loading and jumping to FSBL. Then, FSBL loads DTB, OpenSBI and LinuxBoot into memory.

[0026] OpenSBI first performs low-level initialization, then performs early platform initialization, related hardware device initialization, and final platform initialization, and finally performs secondary boot jump to the Linux Boot kernel;

[0027] The Linux Boot kernel loads u-root as the initramfs;

[0028] The Linux Boot kernel loads the actual Linux kernel image and device tree, and sets the hardware configuration and parameters to start the Linux kernel.

[0029] According to a preferred embodiment of the present invention, ZSBL is executed first, and ZSBL is responsible for loading and jumping to FSBL; then, FSBL loads DTB, OpenSBI, and LinuxBoot into memory, including:

[0030] ZSBL initializes the processor's basic environment, including: setting registers, interrupt vector table, and initializing memory;

[0031] ZSBL loads and jumps to FSBL, which loads DTB, OpenSBI, and LinuxBoot from the storage medium into memory;

[0032] The FSBL initializes the memory controller, peripheral controller, and clock controller, and sets up the memory mapping table. The FSBL is also responsible for loading and executing the bootloader for the next stage from the storage medium.

[0033] According to a preferred embodiment of the present invention, OpenSBI first performs low-level initialization, then performs early platform initialization, initialization of related hardware devices including Hart, Console, PMU, IRQ, IPI, TLB, Timer, ecall, Domain, PMP, and finally platform initialization.

[0034] According to a preferred embodiment of the present invention, the Linux Boot kernel loads the actual Linux kernel image and device tree, and sets hardware configurations and parameters to start the Linux kernel, including:

[0035] The Linux Boot kernel loads the actual Linux kernel image and device tree, and performs hardware initialization and configuration based on the device tree description information. The described objects include: processor, memory, bus, clock, interrupt controller, timer, serial port, power management, storage devices and controllers, input / output devices, interrupt mapping, and the connection relationships between device nodes.

[0036] The Linux Boot kernel transfers control to the Linux kernel, thereby starting the complete operating system environment.

[0037] According to a preferred embodiment of the present invention, DTB, OpenSBI, and Linux Boot are loaded into memory via FSBL, and the method further includes:

[0038] FSBL is responsible for establishing the memory mapping table, initializing some CPU functions, and then transferring control to OpenSBI through jump instructions.

[0039] According to a preferred embodiment of the present invention, the Linux Boot kernel loads u-root as the initramfs, and then further includes:

[0040] u-root uses the EXT4 file system driver to initialize and manage the EXT4 file system, including creating partitions, formatting, mounting, unmounting files and directories, managing the file system, checking and repairing the file system, and configuring file system parameters.

[0041] u-root searches for and parses the Linux kernel's boot configuration file in the EXT4 file system. The configuration file contains multiple boot options, each of which is a single command line containing the path to the Linux kernel and boot parameters.

[0042] According to a preferred embodiment of the present invention, the Linux Boot kernel loads the actual Linux kernel image and device tree, and sets hardware configurations and parameters, and further includes:

[0043] The Linux Boot kernel loads the actual Linux kernel image into memory and sets the necessary boot parameters for the Linux kernel based on the "bootargs" attribute in the device tree;

[0044] The Linux Boot kernel uses the kexec command to run a new kernel and transfer control to the real Linux kernel, thus enabling the full functionality of the Linux operating system.

[0045] A computer device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the steps of a novel Linux Boot method based on a RISC-V server CPU.

[0046] A computer-readable storage medium having a computer program stored thereon, the computer program, when executed by a processor, implementing the steps of a novel Linux Boot method based on a RISC-V server CPU.

[0047] A novel Linux Boot system based on a RISC-V server CPU includes:

[0048] The first loading module is configured to execute ZSBL first after the server CPU is powered on. ZSBL is responsible for loading and jumping to FSBL. Then, FSBL loads DTB, OpenSBI and LinuxBoot into memory.

[0049] The critical component initialization module is configured as follows: OpenSBI first performs low-level initialization, then performs early platform initialization, related hardware device initialization, and final platform initialization, and finally performs secondary boot jump to the Linux Boot kernel;

[0050] The second loading module is configured to load u-root as the initramfs by the Linux Boot kernel.

[0051] The third loading module is configured to load the actual Linux kernel image and device tree into the Linux Boot kernel, and set hardware configurations and parameters to start the Linux kernel.

[0052] The beneficial effects of this invention are as follows:

[0053] 1. By optimizing the boot process and reducing unnecessary steps, this invention enables faster system startup, reduces boot time, and improves user experience and productivity. The Linux Boot boot method can complete server startup in less than 20 seconds, while UEFI requires several minutes.

[0054] 2. By introducing reliable boot components and frameworks, such as OpenSBI and LinuxBoot, this invention ensures system stability and reliability. Furthermore, by using a device tree to describe system hardware configurations and device driver relationships, hardware compatibility issues can be reduced, improving system compatibility and stability.

[0055] 3. By using u-root as the initramfs, this invention provides flexible file system initialization and management capabilities. u-root can perform operations such as initializing, formatting, mounting, and unmounting EXT4 partition file systems, and simultaneously parse the Linux kernel's boot configuration file, allowing system administrators to flexibly configure and manage the boot parameters and paths of multiple Linux kernels.

[0056] 4. This invention improves system boot efficiency and flexibility by simplifying the boot process and reducing reliance on traditional BIOS / UEFI. This invention can be applied to RISC-V architecture servers, providing a beneficial technical solution for fast, reliable, and flexible server system booting. Attached Figure Description

[0057] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the structures shown in these drawings without creative effort.

[0058] Figure 1 This is a flowchart of a Linux Boot method based on a RISC-V server CPU proposed in this invention.

[0059] Figure 2 This is a sample image of the startup configuration file. Detailed Implementation

[0060] The present invention will be further defined below with reference to the accompanying drawings and embodiments, but is not limited thereto. It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of the invention.

[0061] Example 1

[0062] A novel Linux boot method based on a RISC-V server CPU, such as... Figure 1 As shown, it includes:

[0063] S110: After the server CPU is powered on, ZSBL is executed first. ZSBL is responsible for loading and jumping to FSBL. Then, FSBL loads DTB, OpenSBI and LinuxBoot into memory.

[0064] S120: OpenSBI first performs low-level initialization, then performs early platform initialization, related hardware device initialization, and final platform initialization, and finally performs secondary boot jump to the Linux Boot kernel;

[0065] S130: The Linux Boot kernel loads u-root as the initramfs;

[0066] S140: The Linux Boot kernel loads the actual Linux kernel image and device tree, and sets the hardware configuration and parameters to start the Linux kernel.

[0067] Example 2

[0068] The difference between the novel Linux Boot method based on a RISC-V server CPU described in Example 1 and the method described in Example 1 is as follows:

[0069] This embodiment uses the SG2042 EVB development board designed by Beijing Suaneng Technology Co., Ltd. as an example.

[0070] After the SG2042 EVB development board is powered on, ZSBL is executed first. ZSBL is responsible for loading and jumping to FSBL; then, FSBL loads DTB, OpenSBI, and LinuxBoot into memory, including:

[0071] ZSBL is the zeroth stage of the RISC-V server CPU system boot process. It is the boot firmware (Boot ROM) embedded in the processor and located at the processor reset vector address.

[0072] ZSBL initializes the processor's basic environment, including: setting registers, interrupt vector table, and initializing memory;

[0073] ZSBL loads and jumps to FSBL, which loads DTB, OpenSBI, and LinuxBoot from storage media (such as flash memory, hard disk, etc.) into memory;

[0074] In the RISC-V boot process, the ZSBL is a key component. It's a simple firmware program located at the processor reset vector address, responsible for initializing the processor and peripherals, and loading the more complex bootloader. The ZSBL's main task is to establish the basic hardware environment, including setting registers, interrupt vector tables, and initializing memory. The ZSBL typically runs in the initial stages of the boot process before handing control over to the higher-level bootloader, which can then load the operating system or other applications.

[0075] The FSBL (Future System Boot Loader) is the second stage of the bootloader, also known as the main boot loader. It typically resides in non-volatile memory (such as flash memory) and is loaded and executed by the ZSBL (Zero System Boot Loader). The FSBL's primary task is to perform more complex system initialization and configuration. The FSBL initializes the memory controller, peripheral controller, and clock controller, and sets up the memory mapping table so that the operating system or firmware can correctly access and manage system resources. The FSBL is also responsible for loading and executing the next stage bootloader from the storage medium.

[0076] A Data Block (DTB) is a data structure that describes information about computer hardware devices. In RISC-V server systems, DTBs are used to provide hardware configuration information to the operating system. ZSBL loads the DTB file into a specific address in memory so that subsequent software components can read and parse the device information in the DTB.

[0077] OpenSBI first performs low-level initialization, followed by early platform initialization, including initialization of relevant hardware devices such as Hart, Console, PMU, IRQ, IPI, TLB, Timer, ecall, Domain, and PMP, and finally, platform initialization. Once these components are initialized, OpenSBI jumps to the Linux Boot kernel, handing control over to the latter to continue the system boot process. This process ensures that the hardware and basic operating environment are correctly initialized, preparing for the subsequent operating system startup.

[0078] During the startup process of the SG2042 EVB development board, FSBL and OpenSBI are equivalent to the SEC and PEI stages of UEFI, performing minimal necessary hardware initialization. Many subsequent hardware initializations rely on Linux kernel drivers.

[0079] The Linux Boot kernel loads u-root as the initramfs; specifically, after OpenSBI finishes running, it transfers control to the Linux Boot kernel, which can then replace specific UEFI functions with Linux kernel features and boot the actual production kernel onto the computer. Linux Boot-specific kernel configuration files provide the necessary Linux kernel functionality without bloating the BIOS size with unnecessary drivers. Linux Boot loads u-root as the initramfs, which becomes Linux Boot's user space. u-root provides various commands and tools for performing various tasks during the boot process. It can be used to load and configure device drivers, mount file systems, execute system initialization scripts, and more. Once the Linux Boot kernel has completed all necessary initialization and configuration tasks, it transfers control to the first process in the root file system, typically the init process. This process continues the system boot process, loading the core components of the operating system and starting the complete user-space environment.

[0080] When Linux boots, it needs a root filesystem that provides boot and startup utilities. u-root is such a filesystem, written in Go. u-root is a user-space environment that provides the basic libraries and utilities that work within a Linux environment. Linux Boot uses u-root to create an initramfs for this purpose. The initramfs is a root filesystem embedded within the firmware image itself. It is designed to be placed on a flash device along with the Linux kernel as part of the Linux Boot firmware image. u-root is a Go userspace. It contains a toolset of standard Linux applications and commands. u-root can create the initramfs in two different modes: source mode, which includes: a Go toolchain binary, a simple shell, and Go source code that is dynamically compiled via the shell; and Busybox (bb) mode, which is a busybox-like binary containing all the requested utilities.

[0081] The Linux Boot kernel loads the actual Linux kernel image and device tree, and sets hardware configurations and parameters to boot the Linux kernel, including:

[0082] The Linux Boot kernel loads the actual Linux kernel image and device tree, and performs hardware initialization and configuration based on the device tree description information. The described objects include: processor, memory, bus, clock, interrupt controller, timer, serial port, power management, storage devices and controllers, input / output devices, interrupt mapping, and the connection relationships between device nodes.

[0083] The Linux Boot kernel transfers control to the Linux kernel, thus starting the complete operating system environment. This process ensures proper interaction and configuration between the Linux kernel and the hardware, providing the necessary foundation for the normal operation of the operating system.

[0084] Practical comparison shows that: using the traditional startup method, the SG2042 EVB development board takes about 105 seconds from system power-on to the appearance of the operating system login screen, while using the solution of this invention, the SG2042 EVB development board takes about 50 seconds from system power-on to the appearance of the operating system login screen.

[0085] Example 3

[0086] The novel Linux Boot method based on a RISC-V server CPU, as described in Embodiment 1 or 2, differs in that:

[0087] Loading DTB, OpenSBI, and Linux Boot into memory via FSBL, followed by:

[0088] FSBL is responsible for establishing the memory mapping table, initializing some CPU functions, and then transferring control to OpenSBI through jump instructions.

[0089] The Linux Boot kernel loads u-root as the initramfs, which supports drivers for the EXT4 file system. EXT4 partitions support larger file sizes and partition capacities, providing flexible file system initialization and management capabilities. Existing SG2042 EVB development boards use the UEFI implemented with the open-source framework EDK2 during the boot process, which does not support drivers for the EXT4 file system and requires booting GRUB to support it, undoubtedly increasing boot time. Furthermore, UEFI booting GRUB from the FAT file system necessitates implementing an SD card driver within UEFI, while this invention can reuse SD card drivers supported by the Linux kernel. The following also includes:

[0090] u-root uses the EXT4 file system driver to initialize and manage the EXT4 file system, including creating partitions, formatting, mounting, unmounting files and directories, managing the file system, checking and repairing the file system, and configuring file system parameters.

[0091] u-root searches for and parses the Linux kernel's boot configuration file within the EXT4 filesystem. This configuration file contains multiple boot options, each represented as a single command line. The command includes the path to the Linux kernel and boot parameters to ensure the Linux operating system boots correctly.

[0092] Specifically, Figure 2 This is a sample startup configuration file. Figure 2 The startup configuration file contains operating system information for multiple kernel versions, and can also include startup configuration information for multiple platforms, improving server efficiency.

[0093] The Linux Boot kernel loads the actual Linux kernel image and device tree, and sets hardware configurations and parameters, including:

[0094] The Linux Boot kernel loads the actual Linux kernel image into memory and sets the necessary boot parameters for the Linux kernel based on the "bootargs" attribute in the device tree;

[0095] The Linux Boot kernel uses the kexec command to run a new kernel and transfer control to the real Linux kernel, thus enabling the full functionality of the Linux operating system.

[0096] Specifically, during the boot process of the existing SG2042 EVB development board, Linux Boot will by default select the first boot option in the boot configuration file to obtain the target location of the boot files (initrd.img file and vmlinuz file) and kernel boot parameters.

[0097] This invention provides a novel Linux boot method based on a RISC-V server CPU. It offers an efficient and reliable server CPU boot process, ensuring the correct initialization and configuration of critical components such as the processor, memory, and devices, thereby enabling a reliable Linux operating system boot. This method reduces reliance on traditional BIOS or UEFI firmware, providing a more flexible and customizable boot approach, and is suitable for RISC-V architecture server CPUs.

[0098] Example 4

[0099] A computer device includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the steps of the novel Linux Boot boot method based on a RISC-V server CPU as described in any of Examples 1-3.

[0100] Example 5

[0101] A computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of the novel Linux Boot boot method based on a RISC-V server CPU as described in any of Examples 1-3.

[0102] Example 6

[0103] A novel Linux Boot system based on a RISC-V server CPU includes:

[0104] The first loading module is configured to execute ZSBL first after the server CPU is powered on. ZSBL is responsible for loading and jumping to FSBL. Then, FSBL loads DTB, OpenSBI and LinuxBoot into memory.

[0105] The critical component initialization module is configured as follows: OpenSBI first performs low-level initialization, then performs early platform initialization, related hardware device initialization, and final platform initialization, and finally performs secondary boot jump to the Linux Boot kernel;

[0106] The second loading module is configured to load u-root as the initramfs by the Linux Boot kernel.

[0107] The third loading module is configured to load the actual Linux kernel image and device tree into the Linux Boot kernel, and set hardware configurations and parameters to start the Linux kernel.

[0108] The sequence numbers of the above embodiments of the present invention are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0109] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. The computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk), including several instructions to cause a terminal (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of the present invention.

[0110] The embodiments of the present invention have been described above with reference to the accompanying drawings. However, the present invention is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of the present invention without departing from the spirit and scope of the claims. All of these forms are within the protection scope of the present invention.

Claims

1. A novel Linux Boot method based on a RISC-V server CPU, characterized in that, include: After the server CPU is powered on, ZSBL is executed first. ZSBL is responsible for loading and jumping to FSBL. Then, FSBL loads DTB, OpenSBI, and LinuxBoot into memory; OpenSBI first performs low-level initialization, then performs early platform initialization, related hardware device initialization, and final platform initialization, and finally performs secondary boot jump to the Linux Boot kernel; The Linux Boot kernel loads u-root as the initramfs; The Linux Boot kernel loads the actual Linux kernel image and device tree, and sets the hardware configuration and parameters to start the Linux kernel; Loading DTB, OpenSBI, and Linux Boot into memory via FSBL, followed by: FSBL is responsible for establishing the memory mapping table, initializing some CPU functions, and then transferring control to OpenSBI through jump instructions; The Linux Boot kernel loads u-root as the initramfs, and then includes: u-root uses the EXT4 file system driver to initialize and manage the EXT4 file system, including creating partitions, formatting, mounting, unmounting files and directories, managing the file system, checking and repairing the file system, and configuring file system parameters. u-root searches for and parses the Linux kernel's boot configuration file in the EXT4 file system. The configuration file contains multiple boot options, each of which is a single command line containing the path to the Linux kernel and boot parameters.

2. The novel Linux Boot method based on a RISC-V server CPU according to claim 1, characterized in that, First, ZSBL is executed, which is responsible for loading and jumping to FSBL; Then, FSBL loads DTB, OpenSBI, and Linux Boot into memory, including: ZSBL initializes the processor's basic environment, including: setting registers, interrupt vector table, and initializing memory; ZSBL loads and jumps to FSBL, which loads DTB, OpenSBI, and LinuxBoot from the storage medium into memory; The FSBL initializes the memory controller, peripheral controller, and clock controller, and sets up the memory mapping table. The FSBL is also responsible for loading and executing the bootloader for the next stage from the storage medium.

3. The novel Linux Boot method based on a RISC-V server CPU according to claim 1, characterized in that, OpenSBI first performs low-level initialization, then performs early platform initialization, and initialization of related hardware devices, including Hart, Console, PMU, IRQ, IPI, TLB, Timer, ecall, Domain, PMP, and finally platform initialization.

4. A novel Linux Boot method based on a RISC-V server CPU according to claim 1, characterized in that, The Linux Boot kernel loads the actual Linux kernel image and device tree, and sets hardware configurations and parameters to boot the Linux kernel, including: The Linux Boot kernel loads the actual Linux kernel image and device tree, and performs hardware initialization and configuration based on the device tree description information. The described objects include: processor, memory, bus, clock, interrupt controller, timer, serial port, power management, storage devices and controllers, input / output devices, interrupt mapping, and the connection relationships between device nodes. The Linux Boot kernel transfers control to the Linux kernel, thereby starting the complete operating system environment.

5. A novel Linux Boot method based on a RISC-V server CPU according to any one of claims 1-4, characterized in that, The Linux Boot kernel loads the actual Linux kernel image and device tree, and sets hardware configurations and parameters, including: The Linux Boot kernel loads the actual Linux kernel image into memory and sets the boot parameters for the Linux kernel based on the bootargs attribute in the device tree; The Linux Boot kernel uses the kexec command to run a new kernel and transfer control to the real Linux kernel, thus enabling the full functionality of the Linux operating system.

6. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the novel Linux Boot method based on a RISC-V server CPU as described in any one of claims 1-5.

7. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the novel Linux Boot boot method based on a RISC-V server CPU as described in any one of claims 1-5.

8. A novel Linux Boot system based on a RISC-V server CPU, characterized in that, include: The first loading module is configured to execute ZSBL first after the server CPU is powered on. ZSBL is responsible for loading and jumping to FSBL. Then, FSBL loads DTB, OpenSBI, and LinuxBoot into memory; The critical component initialization module is configured as follows: OpenSBI first performs low-level initialization, then performs early platform initialization, related hardware device initialization, and final platform initialization, and finally performs secondary boot jump to the Linux Boot kernel; The second loading module is configured to load u-root as the initramfs by the Linux Boot kernel. The third loading module is configured to load the actual Linux kernel image and device tree into the Linux Boot kernel, and set hardware configurations and parameters to start the Linux kernel. Loading DTB, OpenSBI, and Linux Boot into memory via FSBL, followed by: FSBL is responsible for establishing the memory mapping table, initializing some CPU functions, and then transferring control to OpenSBI through jump instructions; The Linux Boot kernel loads u-root as the initramfs, and then includes: u-root uses the EXT4 file system driver to initialize and manage the EXT4 file system, including creating partitions, formatting, mounting, unmounting files and directories, managing the file system, checking and repairing the file system, and configuring file system parameters. u-root searches for and parses the Linux kernel's boot configuration file in the EXT4 file system. The configuration file contains multiple boot options, each of which is a single command line containing the path to the Linux kernel and boot parameters.

Images