CN117075974A

CN117075974A - Novel EDK2 starting and guiding method based on RISC-V server CPU

Info

Publication number: CN117075974A
Application number: CN202310948530.8A
Authority: CN
Inventors: 戴鸿君; 张真瑜; 李冰; 翟明杰
Original assignee: Shandong University
Current assignee: Shandong University
Priority date: 2023-07-31
Filing date: 2023-07-31
Publication date: 2023-11-17

Abstract

The invention relates to a novel EDK2 starting and guiding method based on a RISC-V server CPU, which comprises the following steps: after the CPU of the server is electrified, initializing the minimum range, and loading the DTB and the EDK2 into a memory; EDK2 completes the work of security verification, efi early initialization and the like; interacting with hardware to finish bottom initialization and equipment initialization; loading and executing the equipment program, and initializing a hardware abstraction layer and running DXE service; fifthly, the GRUB loads a real Linux kernel image and a device tree, and smoothly starts the Linux kernel. The invention reduces the redundancy of the OpenSBI library in the SEC stage, so that the OpenSBI has flexibility and expansibility in the EDK2, and the debugging and updating are simplified. The method increases various possibilities in OpenSBI security verification and mode switching, and realizes more reliable and flexible Linux kernel starting.

Description

Novel EDK2 starting and guiding method based on RISC-V server CPU

Technical Field

The invention relates to the technical field of computers, in particular to a novel EDK2 starting and guiding method based on a RISC-V server CPU.

Background

RISC-V is a processor architecture based on an open instruction set architecture (Open Instruction Set Architecture, ISA), which is gradually becoming a new corner in the server CPU field. In contrast to the mainstream X86 and ARM two-platform architecture in the market, the RISC-V architecture is still at the start-up stage in the server domain, but it has begun to show great potential in the MCU product domain and is another option beyond the ARM architecture. The RISC-V architecture supports three different modes of operation: user mode U-mode (User Mode), supervisor mode S-mode (Supervisor Mode), and machine mode M-mode (Machine Mode). The user mode provides a standard mode of application operation, the supervisor mode is for operating system and virtual machine management, and the machine mode is for low-level operation and initialization at the system level, etc. With the continued development and maturation of the RISC-V architecture, we have reason to believe that it can gain a place in the server CPU domain and exhibit a more active development situation.

UEFI (Unified Extensible Firmware Interface) is a new generation of System firmware interface standard intended to replace the traditional BIOS (Basic Input/Output System), UEFI was originally customized for X86 processors by Intel corporation, but the UEFI standard is not architecture-dependent, and through the continual development of the interface standard of UEFI, it has been commonly used on X86, ARM, etc. processor platforms that support the loading and execution of multiple operating systems, drivers, and applications. An extensible firmware environment is provided with more powerful functions and flexibility.

EDK2 (EFIDevelopment Kit 2) is a development suite that can help developers design, create, and debug UEFI (Unified Extensible Firmware Interface) -based firmware. It contains development libraries, tools, example code, and documents for building UEFI BIOS and UEFI applications. EDK2 is an open source project commonly maintained by companies such as Intel, HP, AMD, inryde Software, microsoft, and the like.

OpenSBI (Open Source Secure Boot and Runtime Firmware) is an open firmware that can be used to support multiple RISC-V devices, it provides general purpose boot-up and runtime firmware functions, including secure booting, runtime environment, and operating system boot-up, that make RISC-V devices more reliable and secure.

The entity of the existing EDK2 starting and guiding method based on the CPU of the RISC-V server is shown as an implementation code EDK2 of the open-source UEFI, and the implementation code EDK2 can provide abundant functions and expandability for the UEFI firmware of the RISC-V server as firmware codes, such as a modularized architecture, advanced driving support, safe starting and a graphical interface. However, when EDK2 is used for RISC-V oriented server CPU, the EDK2 code used references OpenSBI firmware for use as a library. The following problems are presented:

1. code maintenance is difficult: since EDK2 and OpenSBI are two different open source projects, maintained by different teams, respectively, the complexity of the code is increased in EDK2. When one of the EDK2 or OpenSBI updates, additional work may be expended to integrate and resolve conflicts that may arise.

2. Performance degradation: the introduction of OpenSBI may cause additional runtime overhead, affecting the performance of the system. Since OpenSBI acts as an intermediate layer, there may be additional delay in invoking the functionality of EDK2.

3. Safety problem: fusing two different open source items may increase the attack surface and potential security vulnerabilities. Since EDK2 and OpenSBI are developed and maintained by different teams, the security hole of one of the projects may affect the security of the entire system.

Disclosure of Invention

The invention mainly aims to solve the starting problem of a CPU of a RISCV server, and provides a novel EDK2 starting and guiding method based on a CPU of a RISC-V server by aiming at the redundancy of EDK and OpenSBI in the existing UEFI starting process and making an innovative flow of separation and recombination. According to the method, openSBI is split from the SEC stage of EDK2 and placed between the PEI and DXE stages, so that the OpenSBI has flexibility and expansibility in the EDK2, and debugging and updating are simplified. The multiple possibilities are increased in OpenSBI security verification and mode switching. And finally, the more reliable and flexible Linux kernel starting is realized.

Term interpretation:

1. ZSBL (Zero Stage Bootloader): is a bootloader, zsbl is the first phase in the system startup process, responsible for initializing hardware and some basic settings, and transferring system control to the next bootloader. zsbl is typically embedded in ROM or SoC chip internal memory, which uses the most basic instruction set and hardware resources to perform its functions with minimal system resource consumption.

2. DTB (Device Tree Binary) Chinese meaning is a device tree binary file describing the device tree (device tree) architecture. The DTS (Device Tree Source ) file is a source file that is convenient for human reading and understanding, and the dtb file is a binary format file formed by compiling the DTS file by dtc (device tree compiler ), and can be parsed by the linux kernel.

3. DDR (Double Data Rate): DDR is a memory technology that is capable of data transfer twice per clock cycle, providing higher bandwidth and data transfer speeds. In a computer, DDR generally refers to a double data rate type of memory module used in the memory of the computer.

4. PEI Core: PEI (Pre-EFI Initialization) is a phase in the edk2 framework and PEI Core is the Core component of the PEI phase. The PEI phase is part of the UEFI firmware boot-up process and is located at a pre-initialization phase in edk2. In the PEI phase, initialization of system hardware and resources is performed, including initialization of the processor, initialization of the memory, configuration of the interrupt controller, and the like. PEI Core is the Core component of the PEI phase and is responsible for managing the execution flow of the PEI phase and the initialization of the various modules.

5. PEIM (Pre-EFI Initialization Module): the PEIM is a module provided by the UEFI driver for initializing a particular device or providing system services.

6. Hart ID: hart ID is a term in OpenSBI that represents a unique identifier of a processor core. In RISC-V systems, each processor core (Hart) has a unique Hart ID that is used to distinguish between different processor cores. The Hart ID may be a digital or other form of identifier, such as 0, 1, 2, etc. Hart IDs are commonly used to identify and distinguish processor cores, and may be used to perform process scheduling, resource allocation, and communication operations in multi-core systems.

7. BSS (Block Started by Symbol): representing uninitialized data blocks of a program, in a computer program, a BSS segment is a block of memory space that holds global uninitialized static variables and global static variables. These variables are declared at compile time, but do not give the initialized value. The BSS segment is typically cleared when the program is loaded, i.e., all variables are initialized to 0 or null values.

8. sbi _init: sbi _init is a function in OpenSBI for initializing the OpenSBI environment. The sbi _init function is called during the start-up of the OpenSBI, which is responsible for performing some basic initialization operations to prepare the OpenSBI for operation. These initialization operations include: the method comprises the steps of setting an initialization interrupt controller, a clock hardware environment, initializing state information of a processor core and a system configuration global variable, and setting exception handling for processing page errors and illegal instruction exception conditions possibly occurring in a system.

9. Irq (Interrupt Request) an interrupt is a mechanism in a computer system to interrupt the normal execution flow of a processor to handle an emergency or request from an external device. An interrupt request refers to an interrupt signal triggered by an external device or software for informing a processor that a certain event needs to be handled or a certain request is responded to.

10. MMU (Memory Management Unit) it represents a Memory Management Unit (MMU), which is a hardware component in a computer system for managing memory accesses between a processor and the system. It is responsible for converting Virtual addresses (Virtual addresses) into Physical addresses (Physical addresses) and providing memory protection, address mapping, page table management, etc.

11. TLB (Translation Lookaside Buffer): a TLB is a cache that stores the results of virtual to physical address translations. The TLB is used for accelerating the speed of accessing the memory by the processor, and the complete address translation process when accessing the memory each time is avoided by caching the page table entry which is used recently.

12. Timer: timer is a Timer device in the system that provides a time reference and timing function. Initializing Timer involves configuring the frequency and mode of the Timer and setting interrupts to implement the Timer interrupt function.

13. sbi _hsm_preparation_next_jump: sbi _hsm_preparation_next_jump is a function in OpenSBI for preparing the next jump to Secure Monitor mode (Hypervisor).

The technical scheme adopted by the invention is as follows:

a novel EDK2 starting and guiding method based on a RISC-V server CPU comprises the following steps:

after the CPU of the RISC-V server is electrified, the minimum range initialization is carried out in the ZSBL stage, and DTB and EDK2 are loaded into a memory;

in the SEC phase and the PEI phase, the EDK2 completes security verification and EDK2 early-stage initialization work and jumps to OpenSBI;

an OpenSBI phase, interacting with hardware, completing bottom layer initialization and equipment initialization, and jumping back to the DXE phase of EDK 2;

in the DXE stage, the RISC-V server is in an S-mode, loads and executes the equipment program, initializes a hardware abstraction layer and runs the DXE service, and constructs a DXE stage data structure to provide service information for the BDS stage;

the GRUB loads the real Linux kernel image and the device tree, and sets necessary hardware configuration and parameters, wherein the necessary hardware configuration comprises detection, initialization and configuration of hardware devices, and the parameters comprise starting command line parameters, kernel parameters and starting device information, so that the Linux kernel is smoothly started.

According to the invention, the ZSBL stage performs minimum initialization when the RISC-V server is in M-mode, comprising: and the ZSBL stage initializes the basic environment of the processor, including setting registers and an interrupt vector table.

According to the invention, preferably, after the RISC-V server CPU is powered on, the ZSBL stage performs minimum range initialization, and loads DTB and EDK2 into the memory, and then further includes:

in the ZSBL stage, initializing the DDR of the memory, wherein the initializing of the DDR of the memory comprises initializing a memory controller, training the memory, initializing DRAM and memory mapping, adding program codes of the EDK2 to the appointed position of the memory, and transmitting control rights to the EDK2 through a jump instruction.

According to the preferred embodiment of the invention, during the SEC phase, the RISC-V server is in M-mode, and security verification is performed after separation from OpenSBI: in a secure environment, the SEC phase performs a series of security verifications, including verifying the signatures of the boot program and firmware and checking the integrity of the system boot configuration, addressing and jumping to the PEI Core.

In the PEI phase, the RISC-V server is in M-mode for EDK2 pre-initialization operation: and running the PEIM.

According to the invention, in the SEC phase and PEI phase, EDK2 completes security verification and EDK2 early initialization work, and then further comprises: during the OpenSBI phase, the RISC-V server is in an M-mode, and when the RISC-V server interacts with hardware, the initialization work of the processor, the memory and key components of the device is completed, the state of the processor is set, the memory subsystem is initialized, and communication connection is established with external equipment.

According to a preferred embodiment of the present invention, the initialization of the bottom layer comprises: judging hart id, repositioning codes, removing register values for saving equipment tree addresses, removing BSS sections, setting stack pointers, reading equipment information in equipment trees and repositioning the equipment trees;

device initialization by executing sbi _init, including: initializing a control console, initializing irq interrupt and inter-core interrupt, initializing TLB (memory management unit) table of an MMU (memory management unit), and initializing a timer;

the DXE phase entry function of UEFI firmware is jumped to using the sbi _hsm_preparation_next_jump function.

According to the invention, preferably, the RISC-V server is in S-mode, and the EDK2 further comprises:

the EDK2 continues to execute the DXE phase to load and execute the equipment program, and the BDS phase carries out the DXE phase drive to be matched and connected with the actual hardware so as to enable the corresponding equipment to read and write; the TSL phase is a temporary system phase and the RT phase provides runtime services.

According to the present invention, preferably, the device program is loaded and executed, while initializing a hardware abstraction layer and running DXE services, and simultaneously, constructing a DXE phase data structure to provide service information for a BDS phase, including:

device program loading and execution: in the DXE phase, EDK2 loads and executes device programs, including drivers and DXE Core;

hardware abstraction layer initialization: in the DXE phase, EDK2 initializes and provides a hardware abstraction layer so that DXE services interact with hardware devices;

DXE service operation: DXE services include: providing functions and services of system configuration management, memory management and guiding equipment selection; during the DXE phase, EDK2 runs these DXE services;

constructing a DXE phase data structure: the DXE phase data structure includes a system configuration table (System Configuration Tables) and service nodes (Service Nodes with Service Descriptors) with service descriptors.

According to the preferred embodiment of the present invention, the GRUB loads the real Linux kernel image and the device tree, sets necessary hardware configuration and parameters, and smoothly starts the Linux kernel, and further includes:

the GRUB uses the EXT4 file system driver to initialize and manage the EXT4 partition file system, including partition creation, formatting, mounting and unloading operations;

the GRUB searches and analyzes the boot configuration file of the Linux kernel in the EXT4 partition, which includes paths and parameter settings of a plurality of Linux kernels, so as to ensure that the Linux operating system is correctly booted.

A computer device comprising a memory storing a computer program and a processor implementing the steps of a novel EDK2 boot method based on a RISC-V server CPU when the computer program is executed.

A computer readable storage medium having stored thereon a computer program which when executed by a processor implements the steps of a novel EDK2 boot method based on a RISC-V server CPU.

The invention has the beneficial effects that:

1. the starting process is more flexible: the OpenSBI is arranged between the PEI and the DXE, so that the OpenSBI function can be used more flexibly, and the initialization limited to the SEC stage is avoided.

2. Easy to expand: placing the OpenSBI between PEI and DXE makes it easier to extend the functionality of the OpenSBI, such as adding new hardware support and adjusting boot policies, etc.

3. Simplified debugging and updating: placing the OpenSBI between PEI and DXE, the whole startup process becomes easier to debug and understand, and the updating and debugging of the OpenSBI becomes simpler.

4. The safety is improved: security verification can be performed in the OpenSBI, so that security monitoring efficiency is improved. In EDK2, the security protocols and policies provided by UEFI firmware may also be used more flexibly.

5. Providing mode switching: an alternative to placing the SEC and PEI phases in the M-MODE phase is provided during the RISC-V startup phase.

According to the invention, the OpenSBI is arranged between the PEI and the DXE, so that the redundancy of the OpenSBI library in the SEC stage is reduced, the OpenSBI has flexibility and expansibility in the EDK2, and the debugging and updating are simplified. Multiple possibilities are added in OpenSBI security verification and mode switching. The invention is suitable for the server field of RISC-V architecture, and provides a reliable and flexible starting technical solution for a server system.

Drawings

In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings that are required in the embodiments or the description of the prior art will be briefly described, and it is obvious that the drawings in the following description are only some embodiments of the present invention, and other drawings may be obtained according to the structures shown in these drawings without inventive effort for a person skilled in the art.

Fig. 1 is a schematic flow chart of a novel EDK2 start-up guidance method based on a RISC-V server CPU according to the present invention.

Fig. 2 is a detailed starting flow diagram of each stage of the EDK2 based on the RISC-V server CPU according to the novel EDK2 starting guiding method based on the RISC-V server CPU.

Detailed Description

The invention is further defined by, but is not limited to, the following drawings and examples in conjunction with the specification.

Example 1

A novel EDK2 starting and guiding method based on a RISC-V server CPU is shown in figure 1, which embodies the ideas of OpenSBI separation and reconstruction and points out the characteristics of OpenSBI running in the middle section of the EDK2. Comprising the following steps:

during the DXE phase, the RISC-V server is in S-mode, under which EDK2 continues to execute, and during the subsequent phase, UEFI SHELL is entered and the operating system loader (GRUB) is loaded. Loading and executing the equipment program, initializing a hardware abstraction layer and running DXE service, and constructing a DXE stage data structure to provide service information for a BDS stage;

the GRUB loads the real Linux kernel image and the device tree, and sets necessary hardware configuration and parameters, wherein the necessary hardware configuration comprises detection, initialization and configuration of hardware devices, such as a processor, a memory controller, a disk controller and a graphic display adapter; the parameters comprise a starting command line parameter, a kernel parameter and starting equipment information, and the Linux kernel is smoothly started. Hardware initialization: GRUB requires initializing and configuring the hardware devices of a computer so that the operating system can properly communicate with these devices after boot-up. This may be the case. Guiding parameter setting: the GRUB may configure and pass some boot parameters to the operating system kernel. These parameters can be very important.

The invention provides a novel EDK2 starting and guiding method based on a RISC-V server CPU, which can provide a safe and flexible starting process of a server CPU operating system, ensure the correct initialization and configuration of key components such as a processor, a memory, equipment and the like, thereby realizing the reliable starting of a Linux operating system. The method splits OpenSBI from SEC stage and places the OpenSBI between PEI and DXE stage, provides simpler debugging and updating scheme, and is suitable for server CPU of RISC-V architecture.

Example 2

The novel EDK2 boot method based on the RISC-V server CPU according to embodiment 1 is different in that:

as shown in fig. 2, the ZSBL phase performs minimum range initialization when the RISC-V server is in M-mode, including: and the ZSBL stage initializes the basic environment of the processor, including setting registers and an interrupt vector table.

After the RISC-V server CPU is powered on, the ZSBL phase performs minimum range initialization, and loads DTB and EDK2 into the memory, and then further includes:

in the ZSBL stage, initializing the DDR of the memory, wherein the initializing of the DDR of the memory comprises initializing a memory controller, training the memory, initializing DRAM and memory mapping, adding program codes of the EDK2 to the appointed position of the memory, and transmitting control rights to the EDK2 through a jump instruction. Wait for EDK2 to perform further initialization tasks.

During SEC stage, RISC-V server is in M-mode, and security verification is performed after separation from OpenSBI: in a secure environment, the SEC phase performs a series of security verifications to ensure that the start-up of the server is trusted. This includes verifying the signatures of the boot program and firmware, checking the integrity of the system boot configuration, addressing and jumping to the PEI Core.

During the PEI phase, the RISC-V server is in M-mode, and performs EDK2 early-stage initialization work: and running the PEIM. These PEIM's may be considered as "early drivers" of UEFI firmware for managing hardware devices in EDK2.

In the SEC phase and the PEI phase, the EDK2 completes security verification and EDK2 early initialization work, and then further comprises: during the OpenSBI phase, the RISC-V server is in an M-mode, and when the RISC-V server interacts with hardware, the initialization work of the processor, the memory and key components of the device is completed, the state of the processor is set, the memory subsystem is initialized, and communication connection is established with external equipment.

Bottom layer initialization, including: judging hart id, repositioning codes, removing register values for saving equipment tree addresses, removing BSS sections, setting stack pointers, reading equipment information in equipment trees and repositioning the equipment trees; to provide information for the subsequent EDK2 (UEFI firmware) phase.

After the bottom layer initialization is completed, the device initialization is performed by executing sbi _init, which includes: initializing a control console, initializing irq interrupt and inter-core interrupt, initializing TLB (memory management unit) table of an MMU (memory management unit), and initializing a timer;

the DXE phase entry function of UEFI firmware is jumped to using the sbi _hsm_preparation_next_jump function. When these component initializations are completed, openSBI will jump to DXE phase entry function of EDK2 (UEFI firmware) using sbi _hsm_preparation_next_jump function, and in S-mode state, give control to DXE phase, thus continuing the system startup process. Through this process, proper initialization of the hardware and the underlying operating environment is ensured, ready for subsequent operating system starts.

Loading and executing the device program, initializing a hardware abstraction layer and running DXE service, and constructing a DXE stage data structure to provide service information for the BDS stage, wherein the method comprises the following steps:

device program loading and execution: in the DXE phase, EDK2 loads and executes device programs, including drivers (device drivers) and DXE Core (DXE Core);

hardware Abstraction Layer (HAL) initialization: the hardware abstraction layer is a software interface layer that provides access and management of hardware devices. In the DXE phase, EDK2 initializes and provides a hardware abstraction layer so that DXE services interact with hardware devices;

DXE service operation: DXE services are run on a DXE Core basis, the DXE services comprising: providing functions and services of system configuration management, memory management and guiding equipment selection; during the DXE phase, EDK2 runs these DXE services; to accomplish various tasks.

Constructing a DXE phase data structure: the DXE phase also builds some data structures for providing service information for the BDS phase. The DXE phase data structure includes a system configuration table (System Configuration Tables) and service nodes (Service Nodes with Service Descriptors) with service descriptors. The system configuration table is used for storing relevant information of the system and providing the relevant information for the subsequent BDS stage. The service node is used to describe the properties and functions of DXE services and is also used during the BDS phase.

Example 3

The novel EDK2 boot method based on RISC-V server CPU according to embodiment 2 is different in that:

the RISC-V server is in S-mode and EDK2 continues to execute further comprising:

the EDK2 continues to execute the DXE phase to load and execute the equipment program, and the BDS phase carries out the DXE phase drive to be matched and connected with the actual hardware so as to enable the corresponding equipment to read and write; the TSL phase is a temporary system phase, which is an transition phase between EDK2 (UEFI firmware) and an operating system, and the UEFI provides a man-machine interaction interface, can run partial system tools, and uses an operating system loader such as GRUB. The RT phase provides runtime services. In this stage, the operating system loader obtains full control rights, and the EDK2 (UEFI firmware) only performs reserved runtime services to be provided to the operating system loader and the operating system for use.

The GRUB loads the real Linux kernel image and the device tree, and performs hardware initialization and configuration according to the description information of the device tree. It sets parameters such as processor characteristics, memory map, interrupt and timer. Finally, the EDK2 transfers control to the Linux kernel, thereby starting the complete environment of the operating system. This process ensures proper interaction and configuration between the Linux kernel and hardware, providing the necessary basis for proper operation of the operating system.

The GRUB loads the real Linux kernel image and the device tree, sets necessary hardware configuration and parameters, smoothly starts the Linux kernel, and further comprises:

Example 4

A computer device comprising a memory and a processor, the memory storing a computer program, the processor implementing the steps of the novel EDK2 boot method based on a RISC-V server CPU according to any of embodiments 1-3 when executing the computer program.

Example 5

A computer readable storage medium having stored thereon a computer program which, when executed by a processor, implements the steps of the novel EDK2 boot method based on a RISC-V server CPU as described in any of embodiments 1-3.

The foregoing embodiment numbers of the present invention are merely for the purpose of description, and do not represent the advantages or disadvantages of the embodiments.

From the above description of the embodiments, it will be clear to those skilled in the art that the above-described embodiment method may be implemented by means of software plus a necessary general hardware platform, but of course may also be implemented by means of hardware, but in many cases the former is a preferred embodiment. Based on such understanding, the technical solution of the present invention may be embodied essentially or in a part contributing to the prior art in the form of a software product stored in a storage medium (such as ROM/RAM, magnetic disk, optical disk) and including several instructions for causing a terminal (which may be a mobile phone, a computer, a server, an air conditioner, or a network device, etc.) to perform the method according to the embodiments of the present invention.

The embodiments of the present invention have been described above with reference to the accompanying drawings, but the present invention is not limited to the above-described embodiments, which are merely illustrative and not restrictive, and many forms may be made by those having ordinary skill in the art without departing from the spirit of the present invention and the scope of the claims, which are to be protected by the present invention.

Claims

1. The novel EDK2 starting and guiding method based on the RISC-V server CPU is characterized by comprising the following steps:

2. The novel EDK2 boot method based on RISC-V server CPU according to claim 1, wherein the ZSBL phase performs minimum range initialization when RISC-V server is in M-mode, comprising: and the ZSBL stage initializes the basic environment of the processor, including setting registers and an interrupt vector table.

3. The method for starting and booting the novel EDK2 based on the RISC-V server CPU according to claim 1, wherein after the RISC-V server CPU is powered up, the ZSBL phase performs minimum range initialization, and loads DTB and EDK2 into the memory, and further comprising:

4. The novel EDK2 boot method based on RISC-V server CPU according to claim 1, wherein during SEC phase, RISC-V server is in M-mode, and security verification is performed after separation from OpenSBI: in a secure environment, the SEC phase performs a series of security verifications, including verifying the signatures of the boot program and firmware and checking the integrity of the system boot configuration, addressing and jumping to the PEI Core;

further preferably, during the PEI phase, the RISC-V server is in M-mode for EDK2 pre-initialization: and running the PEIM.

5. The method for booting the EDK2 based on the RISC-V server CPU according to claim 1, wherein the EDK2 performs security verification and EDK2 pre-initialization during the SEC phase and the PEI phase, and further comprising: during the OpenSBI phase, the RISC-V server is in an M-mode, and when interacting with hardware, the initialization work of a processor, a memory and key components of equipment is completed, the state of the processor is set, a memory subsystem is initialized, and communication connection is established with external equipment;

further preferred, the bottom layer initialization comprises: judging hart id, repositioning codes, removing register values for saving equipment tree addresses, removing BSS sections, setting stack pointers, reading equipment information in equipment trees and repositioning the equipment trees;

6. The method for booting the EDK2 based on the RISC-V server CPU of claim 1 wherein the RISC-V server is in S-mode and the EDK2 continues to execute further comprising:

7. The method of claim 1, wherein loading and executing the device program while initializing a hardware abstraction layer and running DXE services, and constructing a DXE phase data structure to provide service information for the BDS phase, comprises:

constructing a DXE phase data structure: the DXE phase data structure includes a system configuration table and service nodes with service descriptors.

8. The method for booting a new EDK2 based on a RISC-V server CPU according to any one of claims 1-7, wherein the GRUB loads a real Linux kernel image and a device tree, sets necessary hardware configuration and parameters, and smoothly boots the Linux kernel, further comprising:

9. A computer device comprising a memory and a processor, said memory storing a computer program, characterized in that said processor, when executing said computer program, implements the steps of a novel EDK2 boot method based on a RISC-V server CPU.

10. A computer readable storage medium having stored thereon a computer program, characterized in that the computer program when executed by a processor implements the steps of a novel EDK2 boot method based on a RISC-V server CPU.