A new EDK2 boot method based on RISC-V server CPU

Abstract

The application relates to a novel EDK2 booting method based on a RISC-V server CPU, which comprises the following steps: after the server CPU is powered on, minimum range initialization is carried out, and a DTB and EDK2 are loaded into a memory; EDK2 completes security verification and efi early initialization and the like; interaction with hardware is carried out to complete underlying initialization and device initialization; device programs are loaded and executed, a hardware abstraction layer is initialized and DXE services are run; in the fifth step, GRUB loads a real Linux kernel image and a device tree, and the Linux kernel is successfully started; the application reduces the redundancy of an SEC stage OpenSBI library, makes OpenSBI have flexibility and expandability in EDK2, simplifies debugging and updating, increases diverse possibilities in OpenSBI security verification and mode switching, and realizes more reliable and flexible Linux kernel starting.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a novel EDK2 boot method based on a RISC-V server CPU. Background Technology

[0002] RISC-V is a processor architecture based on the Open Instruction Set Architecture (ISA) and is gradually emerging in the server CPU market. Compared to the mainstream x86 and ARM platform architectures, RISC-V is still in its early stages in the server field, but it has already begun to demonstrate strong potential in the MCU product market and is becoming an alternative to the ARM architecture. The RISC-V architecture supports three different operating modes: User Mode (U-mode), Supervisor Mode (S-mode), and Machine Mode (M-mode). User Mode provides the standard mode for application execution, Supervisor Mode is used for operating system and virtual machine management, and Machine Mode is used for low-level system operations and initialization. With the continuous development and maturation of the RISC-V architecture, we have reason to believe that it can gradually gain a foothold in the server CPU market and show a more active development trend.

[0003] UEFI (Unified Extensible Firmware Interface) is a next-generation system firmware interface standard designed to replace the traditional BIOS (Basic Input / Output System). Originally developed by Intel for x86 processors, UEFI is architecture-independent. Through continuous development, the UEFI interface standard is now widely used on x86, ARM, and other processor platforms, supporting the loading and execution of multiple operating systems, drivers, and applications. It provides a scalable firmware environment with greater functionality and flexibility.

[0004] EDK2 (EFI Development Kit 2) is a development kit that helps developers design, create, and debug UEFI (Unified Extensible Firmware Interface) based firmware. It includes development libraries, tools, sample code, and documentation for building UEFI BIOS and UEFI applications. EDK2 is an open-source project maintained by companies such as Intel, HP, AMD, Insyde Software, and Microsoft.

[0005] OpenSBI (Open Source Secure Boot and Runtime Firmware) is an open-source firmware that can be used to support multiple RISC-V devices. It provides common boot and runtime firmware features, including secure boot, runtime environment, and operating system startup, making RISC-V devices more reliable and secure. OpenSBI aims to provide a standard boot and runtime environment for the RISC-V ecosystem, making RISC-V devices easier to develop, port, and maintain. It can run on different processor architectures, operating systems, and devices, including embedded devices, servers, network devices, and smartphones.

[0006] The existing EDK2 boot method for RISC-V server CPUs is manifested as the open-source UEFI implementation code EDK2. As firmware code, it provides rich functionality and extensibility for RISC-V server UEFI firmware, such as modular architecture, advanced driver support, secure boot, and a graphical interface. However, when using EDK2 for RISC-V server CPUs, the EDK2 code references the OpenSBI firmware as a library, which presents the following problems:

[0007] 1. Difficult code maintenance: Because EDK2 and OpenSBI are two different open-source projects maintained by different teams, the complexity of the code in EDK2 is increased. When either EDK2 or OpenSBI is updated, additional work may be required to integrate them and resolve potential conflicts.

[0008] 2. Performance Degradation: The introduction of OpenSBI may result in additional runtime overhead, impacting system performance. Since OpenSBI acts as an intermediate layer, there may be additional latency when calling EDK2 functions.

[0009] 3. Security Issues: Merging two different open-source projects may increase the attack surface and potential security vulnerabilities. Since EDK2 and OpenSBI are developed and maintained by different teams, a security vulnerability in one project could affect the security of the entire system. Summary of the Invention

[0010] The primary objective of this invention is to address the booting issues of RISC-V server CPUs. It innovatively separates and reassembles the redundant EDK and OpenSBI processes in existing UEFI boot procedures, providing a novel EDK2 boot method based on RISC-V server CPUs. This method separates OpenSBI from the SEC stage of EDK2 and places it between the PEI and DXE stages, enhancing OpenSBI's flexibility and scalability within EDK2 and simplifying debugging and updates. It also increases the possibilities for OpenSBI security verification and mode switching. Ultimately, this results in a more reliable and flexible Linux kernel boot process.

[0011] Terminology Explanation:

[0012] 1. ZSBL (Zero Stage Bootloader): This is a bootloader program. ZSBL is the first stage in the system startup process, responsible for initializing hardware and some basic settings, as well as transferring system control to the next bootloader. ZSBL is usually embedded in ROM or the internal memory of the SoC chip. It uses the most basic instruction set and hardware resources to complete its functions with minimal system resource consumption.

[0013] 2. DTB (Device Tree Binary): This file describes the device tree architecture. While DTS (Device Tree Source) files are human-readable and understandable source files, DTB files are binary format files compiled from DTS files by DTC (Device Tree Compiler), and can be parsed by the Linux kernel.

[0014] 3. DDR (Double Data Rate): DDR is a memory technology that enables two data transfers per clock cycle, providing higher bandwidth and data transfer speeds. In computers, DDR typically refers to memory modules using a double data rate (DDR) architecture.

[0015] 4. PEI Core: PEI (Pre-EFI Initialization) is a phase within the edk2 framework, and the PEI Core is the core component of this phase. The PEI phase is part of the UEFI firmware boot process and resides in the early initialization stage of edk2. During the PEI phase, system hardware and resource initialization is performed, including processor initialization, memory initialization, and interrupt controller configuration. The PEI Core, as the core component of the PEI phase, is responsible for managing the execution flow of the PEI phase and the initialization of each module.

[0016] 5. PEIM (Pre-EFI Initialization Module): PEIM is a module provided by the UEFI driver, used to initialize specific devices or provide system services.

[0017] 6. Hart ID: Hart ID is a term in OpenSBI that represents a unique identifier for a processor core. In a RISC-V system, each processor core (Hart) has a unique Hart ID to distinguish different processor cores. The Hart ID can be a number or other form of identifier, such as 0, 1, 2, etc. Hart IDs are typically used to identify and distinguish processor cores, and in multi-core systems, they can be used for operations such as process scheduling, resource allocation, and communication.

[0018] 7. BSS (Block Started by Symbol): Represents the uninitialized data block of a program. In a computer program, the BSS segment is a memory space that stores uninitialized global static variables and global static variables. These variables are declared at compile time but are not given initial values. The BSS segment is usually zeroed out when the program is loaded, meaning all variables are initialized to 0 or null values.

[0019] 8. `sbi_init`: `sbi_init` is a function in OpenSBI used to initialize the OpenSBI environment. The `sbi_init` function is called during the OpenSBI startup process. It is responsible for performing some basic initialization operations to prepare OpenSBI for operation. These initialization operations include: setting up and initializing the interrupt controller and clock hardware environment; initializing the processor core status information and system configuration global variables; and setting up exception handling to handle page faults and illegal instruction exceptions that may occur in the system.

[0020] 9. Irq (Interrupt Request): Represents an interrupt request. In a computer system, an interrupt is a mechanism that can interrupt the normal execution flow of the processor to handle urgent events or requests from external devices. An interrupt request is an interrupt signal triggered by an external device or software, used to notify the processor that it needs to handle an event or respond to a request.

[0021] 10. MMU (Memory Management Unit): The Memory Management Unit (MMU) is a hardware component in a computer system used to manage memory access between the processor and the system. It is responsible for translating virtual addresses into physical addresses and provides functions such as memory protection, address mapping, and page table management.

[0022] 11. TLB (Translation Lookaside Buffer): TLB is a cache used to store the results of virtual address to physical address translation. TLB is used to speed up processor access to memory by caching recently used page table entries, avoiding the full address translation process every time memory is accessed.

[0023] 12. 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.

[0024] 13. sbi_hsm_prepare_next_jump: sbi_hsm_prepare_next_jump is a function in OpenSBI used to prepare for the next jump to the Hypervisor (Secure Monitor) mode.

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

[0026] A novel EDK2 boot method based on a RISC-V server CPU includes:

[0027] After the RISC-V server CPU is powered on, the ZSBL stage performs minimal initialization and loads DTB and EDK2 into memory;

[0028] During the SEC and PEI phases, EDK2 completes security verification and initialization work, and then jumps to OpenSBI.

[0029] During the OpenSBI phase, interaction with the hardware is performed to complete the underlying initialization and device initialization, and then the process jumps back to the DXE phase of EDK2.

[0030] During the DXE phase, the RISC-V server is in S-mode, loading and executing the device program, initializing the hardware abstraction layer and running the DXE service, and building the DXE phase data structure to provide service information for the BDS phase.

[0031] GRUB loads the actual Linux kernel image and device tree, and sets the necessary hardware configurations and parameters. The necessary hardware configurations include the detection, initialization, and configuration of hardware devices, and the parameters include boot command-line arguments, kernel parameters, and boot device information, thus successfully booting the Linux kernel.

[0032] According to a preferred embodiment of the present invention, the ZSBL stage performs minimal initialization, during which the RISC-V server is in M-mode, including: the ZSBL stage, which initializes the basic environment of the processor, including setting registers and interrupt vector tables.

[0033] According to a preferred embodiment of the present invention, after the RISC-V server CPU is powered on, the ZSBL stage performs minimal initialization and loads DTB and EDK2 into memory, and then further includes:

[0034] In the ZSBL phase, the initialization of DDR memory is performed. The initialization of DDR memory includes memory controller initialization, memory training, DRAM initialization and memory mapping. The EDK2 program code is added to the specified memory location, and control is transferred to EDK2 through jump instructions.

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

[0036] According to a preferred embodiment of the present invention, during the PEI stage, the RISC-V server is in M-mode and performs EDK2 pre-initialization work: running PEIM.

[0037] According to a preferred embodiment of the present invention, during the SEC and PEI phases, EDK2 completes security verification and EDK2 pre-initialization work. Afterwards, during the OpenSBI phase, the RISC-V server is in M-mode. When interacting with the hardware, it completes the initialization of the processor, memory, and key components of the device, sets the processor state, initializes the memory subsystem, and establishes communication connections with external devices.

[0038] According to a preferred embodiment of the present invention, the underlying initialization includes: determining the HART ID, code relocation, clearing register values ​​except those storing device tree addresses, clearing the BSS segment, setting the stack pointer, reading device information from the device tree, and device tree relocation;

[0039] Device initialization is performed by executing sbi_init, including: console initialization, IRQ interrupt and inter-core interrupt initialization, MMU TLB table initialization, and timer initialization.

[0040] The sbi_hsm_prepare_next_jump function is used to jump to the DXE stage entry function of the UEFI firmware.

[0041] According to a preferred embodiment of the present invention, when the RISC-V server is in S-mode, EDK2 continues to execute, further including:

[0042] EDK2 continues the DXE stage to load and execute the device program, the BDS stage to match and connect the DXE stage driver with the actual hardware, and enable the corresponding device to read and write; the TSL stage is a temporary system stage, and the RT stage provides runtime services.

[0043] According to a preferred embodiment of the present invention, the device program is loaded and executed, the hardware abstraction layer is initialized and the DXE service is run, and a DXE stage data structure is constructed to provide service information for the BDS stage, including:

[0044] Device program loading and execution: During the DXE phase, EDK2 loads and executes device programs, including drivers and DXECore;

[0045] Hardware Abstraction Layer Initialization: During the DXE phase, EDK2 initializes and provides the Hardware Abstraction Layer so that DXE services can interact with hardware devices;

[0046] DXE service operation: DXE services include providing functions and services for system configuration management, memory management, and boot device selection; during the DXE phase, EDK2 runs these DXE services;

[0047] Constructing the DXE stage data structure: The DXE stage data structure includes system configuration tables and service nodes with service descriptors.

[0048] According to a preferred embodiment of the present invention, GRUB loads the actual Linux kernel image and device tree, and sets the necessary hardware configurations and parameters to successfully boot the Linux kernel, further comprising:

[0049] GRUB uses the EXT4 file system driver to initialize and manage EXT4 partition file systems, including partition creation, formatting, mounting, and unmounting operations.

[0050] GRUB searches for and parses the Linux kernel boot configuration file in the EXT4 partition, which includes the paths and parameter settings for multiple Linux kernels to ensure the Linux operating system boots correctly.

[0051] 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 EDK2 boot method based on a RISC-V server CPU.

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

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

[0054] 1. More flexible startup process: Placing OpenSBI between the PEI and DXE stages allows for more flexible use of OpenSBI functions, avoiding the limitation of initialization to only the SEC stage.

[0055] 2. Easy to expand: Placing OpenSBI between PEI and DXE makes it easier to expand OpenSBI's functionality, such as adding new hardware support and adjusting boot strategies.

[0056] 3. Simplified debugging and updates: By placing OpenSBI between PEI and DXE, the entire startup process becomes easier to debug and understand, and updating and debugging OpenSBI also becomes simpler.

[0057] 4. Enhanced Security: Security verification can be performed in OpenSBI, improving the efficiency of security monitoring. EDK2 also allows for more flexible use of security protocols and policies provided by UEFI firmware.

[0058] 5. Provides mode switching: During the RISC-V boot phase, an option is provided to place the SEC and PEI stages in M-MODE.

[0059] This invention places OpenSBI between PEI and DXE, reducing redundancy in the OpenSBI library during the SEC phase. This makes OpenSBI more flexible and scalable in EDK2, simplifying debugging and updates. It also increases the possibilities for OpenSBI security verification and mode switching. This invention is applicable to the RISC-V architecture server field, providing a reliable and flexible boot technology solution for server systems. Attached Figure Description

[0060] 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.

[0061] Figure 1 This is a flowchart illustrating a novel EDK2 boot method based on a RISC-V server CPU proposed in this invention.

[0062] Figure 2 This is a schematic diagram illustrating the detailed boot process of a novel EDK2 boot method based on a RISC-V server CPU, as proposed in this invention, at each stage. Detailed Implementation

[0063] The present invention will be further defined below with reference to the accompanying drawings and embodiments, but is not limited thereto.

[0064] Example 1

[0065] A novel EDK2 boot method based on a RISC-V server CPU, such as... Figure 1 As shown, this illustrates the concept of separation and reconstruction in OpenSBI, and highlights the characteristics of OpenSBI running in the EDK2 middleware. These include:

[0066] After the RISC-V server CPU is powered on, the ZSBL stage performs minimal initialization and loads DTB and EDK2 into memory;

[0067] During the SEC and PEI phases, EDK2 completes security verification and initialization work, and then jumps to OpenSBI.

[0068] During the OpenSBI phase, interaction with the hardware is performed to complete the underlying initialization and device initialization, and then the process jumps back to the DXE phase of EDK2.

[0069] During the DXE phase, the RISC-V server is in S-mode. In S-mode, EDK2 continues execution, and in subsequent phases, it enters the UEFI SHELL and loads the operating system loader (GRUB). It loads and executes the device program, initializes the hardware abstraction layer and runs the DXE service, and simultaneously constructs the DXE phase data structure to provide service information for the BDS phase.

[0070] GRUB loads the actual Linux kernel image and device tree, and sets the necessary hardware configurations and parameters. Necessary hardware configuration includes the detection, initialization, and configuration of hardware devices, such as the processor, memory controller, disk controller, and graphics adapter. Parameters include boot command-line arguments, kernel parameters, and boot device information to successfully boot the Linux kernel. Hardware initialization: GRUB needs to initialize and configure the computer's hardware devices so that the operating system can communicate correctly with these devices after booting. This may take place over time. Boot parameter settings: GRUB can configure and pass several boot parameters to the operating system kernel. These parameters can be very important.

[0071] This invention provides a novel EDK2 boot method based on a RISC-V server CPU, offering a secure and flexible server CPU operating system boot process. It ensures the correct initialization and configuration of critical components such as the processor, memory, and devices, thereby achieving a reliable Linux operating system boot. This method separates OpenSBI from the SEC stage and places it between the PEI and DXE stages, providing a simpler debugging and update solution suitable for RISC-V architecture server CPUs.

[0072] Example 2

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

[0074] like Figure 2 As shown, the ZSBL phase performs minimal initialization. At this time, the RISC-V server is in M-mode, which includes: the ZSBL phase, which initializes the processor's basic environment, including setting registers and interrupt vector tables.

[0075] After the RISC-V server CPU powers on, the ZSBL phase performs minimal initialization and loads DTB and EDK2 into memory, followed by:

[0076] In the ZSBL phase, DDR memory initialization is performed. This initialization includes memory controller initialization, memory training, DRAM initialization, and memory mapping. The EDK2 program code is added to the specified memory location, and control is transferred to EDK2 via a jump instruction. Then, it waits for EDK2 to perform further initialization tasks.

[0077] During the SEC phase, the RISC-V server is in M-mode and undergoes security verification after being decoupled from OpenSBI: In a secure environment, the SEC phase performs a series of security verifications to ensure the server's boot is trustworthy. This includes verifying the signatures of the bootloader and firmware, checking the integrity of the system boot configuration, addressing, and jumping to the PEI Core.

[0078] During the PEI phase, the RISC-V server is in M-mode and performs EDK2 pre-initialization work: running PEIMs. These PEIMs can be considered "early drivers" of the UEFI firmware, used to manage hardware devices in EDK2.

[0079] During the SEC and PEI phases, EDK2 completes security verification and EDK2 initialization. Afterwards, during the OpenSBI phase, the RISC-V server is in M-mode. When interacting with the hardware, it completes the initialization of key components such as the processor, memory, and devices, sets the processor state, initializes the memory subsystem, and establishes communication connections with external devices.

[0080] Low-level initialization includes: determining the HART ID, code relocation, clearing register values ​​except those storing device tree addresses, clearing the BSS segment, setting the stack pointer, reading device information from the device tree, and device tree relocation; to provide information for the subsequent EDK2 (UEFI firmware) stage.

[0081] After the underlying initialization is completed, device initialization is performed by executing sbi_init, including: console initialization, IRQ interrupt and inter-core interrupt initialization, MMU TLB table initialization, and timer initialization;

[0082] The `sbi_hsm_prepare_next_jump` function jumps to the DXE stage entry function of the UEFI firmware. After these components are initialized, OpenSBI uses `sbi_hsm_prepare_next_jump` to jump to the DXE stage entry function of EDK2 (UEFI firmware) and enters S-mode, handing control over to the DXE stage to continue the system boot process. This process ensures the hardware and basic operating environment are correctly initialized, preparing for the subsequent operating system boot.

[0083] The device program is loaded and executed, the Hardware Abstraction Layer (HAL) is initialized and the DXE service is run. Simultaneously, the DXE stage data structure is constructed to provide service information for the BDS stage, including:

[0084] Device program loading and execution: During the DXE stage, EDK2 loads and executes device programs, including device drivers and the DXE Core.

[0085] Hardware Abstraction Layer (HAL) Initialization: The Hardware Abstraction Layer is a software interface layer used to provide access to and management of hardware devices. During the DXE phase, EDK2 initializes and provides the Hardware Abstraction Layer so that DXE services can interact with hardware devices;

[0086] DXE Service Operation: The DXE service runs on top of the DXE Core. The DXE service includes functions and services such as providing system configuration management, memory management, and boot device selection. During the DXE phase, EDK2 runs these DXE services to complete various tasks.

[0087] Building DXE Phase Data Structures: The DXE phase also builds several data structures to provide service information for the BDS phase. These data structures include System Configuration Tables and Service Nodes with Service Descriptors. The System Configuration Tables store relevant system information for use in the subsequent BDS phase. Service Nodes describe the attributes and functions of the DXE services and are also used in the BDS phase.

[0088] Example 3

[0089] The difference between the novel EDK2 boot method based on a RISC-V server CPU described in Example 2 and the method described in Example 2 is as follows:

[0090] When the RISC-V server is in S-mode, EDK2 continues to execute, including:

[0091] EDK2 continues with the DXE stage, loading and executing device programs. The BDS stage matches the DXE stage drivers with the actual hardware, enabling read and write operations on the corresponding devices. The TSL stage is a temporary system stage, a transitional phase between EDK2 (UEFI firmware) and the operating system. During this stage, UEFI provides a human-machine interface, allowing the execution of some system tools and the use of operating system loader tools such as GRUB. The RT stage provides runtime services. In this stage, the operating system loader gains full control, and EDK2 (UEFI firmware) only provides runtime services for use by the operating system loader and the operating system.

[0092] GRUB loads the actual Linux kernel image and device tree, and performs hardware initialization and configuration based on the device tree's description information. It sets parameters such as processor characteristics, memory mappings, interrupts, and timers. Finally, EDK2 transfers control to the Linux kernel, thus starting the complete operating system environment. This process ensures correct interaction and configuration between the Linux kernel and the hardware, providing the necessary foundation for the normal operation of the operating system.

[0093] GRUB loads the actual Linux kernel image and device tree, sets the necessary hardware configurations and parameters, and successfully boots the Linux kernel. It also includes:

[0094] GRUB uses the EXT4 file system driver to initialize and manage EXT4 partition file systems, including partition creation, formatting, mounting, and unmounting operations.

[0095] GRUB searches for and parses the Linux kernel boot configuration file in the EXT4 partition, which includes the paths and parameter settings for multiple Linux kernels to ensure the Linux operating system boots correctly.

[0096] Example 4

[0097] 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 EDK2 boot method based on a RISC-V server CPU as described in any of Examples 1-3.

[0098] Example 5

[0099] 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 EDK2 boot method based on a RISC-V server CPU as described in any of Examples 1-3.

[0100] 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.

[0101] 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.

[0102] 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 EDK2 boot method based on a RISC-V server CPU, characterized in that, include: After the RISC-V server CPU is powered on, the ZSBL stage performs minimal initialization and loads DTB and EDK2 into memory; During the SEC and PEI phases, EDK2 completes security verification and initialization work, and then jumps to OpenSBI. During the OpenSBI phase, interaction with the hardware is performed to complete the underlying initialization and device initialization, and then the process jumps back to the DXE phase of EDK2. During the DXE phase, the RISC-V server is in S-mode, loading and executing the device program, initializing the hardware abstraction layer and running the DXE service, and building the DXE phase data structure to provide service information for the BDS phase. GRUB loads the actual Linux kernel image and device tree, and sets the hardware configuration and parameters. The hardware configuration includes the detection, initialization and configuration of hardware devices, and the parameters include the boot command line parameters, kernel parameters, boot device information, and successfully boots the Linux kernel. During the SEC and PEI phases, EDK2 completes security verification and EDK2 initialization. Afterwards, during the OpenSBI phase, the RISC-V server is in M-mode. When interacting with the hardware, it completes the initialization of the processor, memory, and key device components, sets the processor state, initializes the memory subsystem, and establishes communication connections with external devices. Low-level initialization includes: determining the HART ID, code relocation, clearing register values ​​except those storing device tree addresses, clearing the BSS segment, setting the stack pointer, reading device information from the device tree, and device tree relocation. Device initialization is performed by executing sbi_init, including: console initialization, IRQ interrupt and inter-core interrupt initialization, MMU TLB table initialization, and timer initialization. The sbi_hsm_prepare_next_jump function is used to jump to the DXE stage entry function of the UEFI firmware.

2. The novel EDK2 boot method based on a RISC-V server CPU according to claim 1, characterized in that, The ZSBL phase performs minimal initialization. At this time, the RISC-V server is in M-mode, which includes: the ZSBL phase, which initializes the processor's basic environment, including setting registers and interrupt vector tables.

3. The novel EDK2 boot method based on a RISC-V server CPU according to claim 1, characterized in that, After the RISC-V server CPU powers on, the ZSBL phase performs minimal initialization and loads DTB and EDK2 into memory, followed by: In the ZSBL phase, the initialization of DDR memory is performed. The initialization of DDR memory includes memory controller initialization, memory training, DRAM initialization and memory mapping. The EDK2 program code is added to the specified memory location, and control is transferred to EDK2 through jump instructions.

4. A novel EDK2 boot method based on a RISC-V server CPU according to claim 1, characterized in that, During the SEC phase, the RISC-V server is in M-mode and undergoes security verification after being separated from OpenSBI: In a secure environment, the SEC phase performs a series of security verifications, including verifying the signatures of the bootloader 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 initialization work: running PEIM.

5. A novel EDK2 boot method based on a RISC-V server CPU according to claim 1, characterized in that, When the RISC-V server is in S-mode, EDK2 continues to execute, including: EDK2 continues the DXE stage to load and execute the device program, the BDS stage to match and connect the DXE stage driver with the actual hardware, and enable the corresponding device to read and write; the TSL stage is a temporary system stage, and the RT stage provides runtime services.

6. A novel EDK2 boot method based on a RISC-V server CPU according to claim 1, characterized in that, The device program is loaded and executed, the Hardware Abstraction Layer (HAL) is initialized and the DXE service is run. Simultaneously, the DXE stage data structure is constructed to provide service information for the BDS stage, including: Device program loading and execution: During the DXE phase, EDK2 loads and executes device programs, including drivers and DXECore; Hardware Abstraction Layer Initialization: During the DXE phase, EDK2 initializes and provides the Hardware Abstraction Layer so that DXE services can interact with hardware devices; DXE service operation: DXE services include providing functions and services for system configuration management, memory management, and boot device selection; during the DXE phase, EDK2 runs these DXE services; Constructing the DXE stage data structure: The DXE stage data structure includes a system configuration table and service nodes with service descriptors.

7. A novel EDK2 boot method based on a RISC-V server CPU according to any one of claims 1-6, characterized in that, GRUB loads the actual Linux kernel image and device tree, sets hardware configurations and parameters, and successfully boots the Linux kernel. It also includes: GRUB uses the EXT4 file system driver to initialize and manage EXT4 partition file systems, including partition creation, formatting, mounting, and unmounting operations. GRUB searches for and parses the Linux kernel boot configuration file in the EXT4 partition, which includes the paths and parameter settings for multiple Linux kernels to ensure the Linux operating system boots correctly.

8. 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 EDK2 boot method based on a RISC-V server CPU as described in any one of claims 1-7.

9. 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 EDK2 boot method based on a RISC-V server CPU as described in any one of claims 1-7.

Images