OpenSBI starting method and system of risc-v soc based on FPGA

Abstract

The application is suitable for the technical field of computer system starting, and provides an OpenSBI starting method and system of a RISC-V SoC based on FPGA, the system comprises a hardware abstraction layer, a boot loading layer, a privilege management layer and a kernel execution layer, and each layer realizes data interaction and process connection through a standardized interface; through the layered design of FPGA hardware initialization, SPL / U-Boot firmware loading, OpenSBI privilege mode configuration and kernel starting, the modular management of the starting process is realized, the system coupling degree is reduced, various storage media and operating system types are supported, the hardware abstraction is realized through the OpenSBI standard interface, it is convenient to extend new peripherals or upgrade the RISC-V architecture version in the future, the standardized starting process reduces the adaptation workload of hardware and firmware, and it is convenient to debug and quickly iterate and develop.

Description

Technical Field

[0001] This invention relates to the field of computer system boot technology, specifically to an OpenSBI boot method and system based on an FPGA-based RISC-V SoC. Background Technology

[0002] Current FPGA-based RISC-V SoC boot processes primarily rely on traditional firmware (such as U-Boot) to directly load the operating system, lacking systematic management of RISC-V privileged modes (such as switching from M-mode to S-mode). Existing OpenSBI integration solutions suffer from timing mismatches between hardware initialization and firmware loading. FPGA-specific dynamic clock configurations (such as PLL frequency switching) and memory initializations (such as DDRPHY training) are independent of OpenSBI's privileged mode configuration processes, frequently leading to inconsistent hardware states due to timing races during boot. For example, firmware images in the virtual address space may be incorrectly loaded before the MMU is initialized, privileged mode switching logic is missing, and traditional solutions fail to clearly define the permission boundaries between M-mode and S-mode, thus failing to effectively isolate memory access between user space and kernel space. The system does not strictly adhere to the RISC-V privileged architecture specification and fails to save privilege status through the MPRV (Machine Privilege Reduction and Restoration) field of the mstatus register. This allows user-space programs to access kernel-level registers (such as mtvec and mscratch) through illegal instructions, resulting in serious security vulnerabilities. The multi-stage loading mechanism is incomplete, lacking the layered loading design of SPL (Secondary Program Loader) and U-Boot. Firmware image verification (such as SHA-256 hash verification) and peripheral driver initialization (such as QSPIFlash controller) are performed in a single stage, resulting in a lengthy boot process with poor fault tolerance. If any part fails, the entire system must be restarted.

[0003] In summary, most existing technologies have the following drawbacks:

[0004] 1. Fragmented startup process: Hardware initialization (completed by QSPIBootloader provided by FPGA vendor), firmware loading (directly taken over by U-Boot), and privileged mode switching (implemented by operating system kernel) lack standardized coordination mechanisms. OpenSBI adaptation for different FPGA platforms requires redesigning timing logic, which increases R&D costs.

[0005] 2. Insufficient security in privileged mode: The RISC-V Sv39 / Sv48 virtual address translation mechanism is not used to isolate user space and kernel space memory. User programs can access hardware control registers (such as the PLIC interrupt controller register) through out-of-bounds pointers, which poses a risk of being attacked by malicious code. According to the CVE vulnerability database, this type of privilege vulnerability accounts for 42% of RISC-V system security incidents.

[0006] 3. Limited scalability: Traditional solutions use single-core boot logic, which makes it difficult to support the collaborative booting of multi-core RISC-V processors (such as the SiFive U74 quad-core architecture). In multi-HAT scenarios, the lack of a standardized inter-processor interrupt (IPI) distribution mechanism results in inter-core communication latency of up to microseconds, severely impacting parallel computing performance.

[0007] Therefore, in view of the above situation, there is an urgent need to provide an OpenSBI boot method and system based on FPGA-based RISC-V SoC to overcome the shortcomings in current practical applications. Summary of the Invention

[0008] The purpose of this invention is to provide an OpenSBI boot method and system for FPGA-based RISC-V SoC, effectively solving the problems mentioned in the background art.

[0009] This invention is implemented as follows: the OpenSBI boot system based on FPGA-based RISC-V SoC includes a hardware abstraction layer, a bootloader layer, a privilege management layer, and a kernel execution layer. Each layer achieves data interaction and process connection through standardized interfaces.

[0010] The hardware abstraction layer is used to implement the hardware initialization of the FPGA, including RV64IMAFD instruction set extension, five-stage pipeline design, L1 instruction cache and data cache configuration, DDR4 controller design and peripheral interface integration, mapping hardware configuration registers to a specific address space and supporting 32-bit atomic operations.

[0011] The bootloader layer includes an SPL stage and a U-Boot stage. The SPL stage is embedded in the FPGA on-chip ROM, loads the U-Boot image from the storage medium through the DMA channel, and completes DDR4 memory initialization, CLINT interrupt controller configuration, and page table mapping establishment. The U-Boot stage provides a Shell command line through the UART interface to select the boot mode, reads the OpenSBI firmware type and loads it into a specified area of ​​memory, and performs image verification.

[0012] The privileged management layer is OpenSBI, which is used to configure RISC-V registers, enable interrupts, initialize floating-point units and compressed instruction units, realize privileged mode switching from M-mode to S-mode, and realize permission isolation and management through platform-level initialization, inter-processor interrupts and console character output functions.

[0013] The kernel execution layer is used to read the kernel binary image from the storage medium, load it into a specified memory location through the interface provided by OpenSBI, support the transfer of hardware configuration information through device tree files, as well as the loading and mounting of memory file systems or block device file systems, and the transfer of boot parameters.

[0014] As a further aspect of the present invention: the DDR4 controller in the hardware abstraction layer is designed based on the AXI4-Stream protocol, supports a data rate of 3200MT / s, and is connected to the interrupt controller and GPIO controller peripherals via the APB bus. The integrated peripheral interfaces include UART, GPIO, SPI, SD card controller and JTAG debugging interface.

[0015] As a further aspect of the present invention: in the SPL stage of the bootloader layer, DDR4 memory initialization calibrates the DQ / DQS timing through the PHY training sequence, the CLINT interrupt controller configuration sets the inter-core interrupt IPI queue depth to 16, and the page table mapping maps the 0x8000_0000-0xFFFF_FFFF address space to physical memory.

[0016] As a further aspect of the present invention: in the U-Boot stage of the bootloader layer, the image verification adopts the CRC32 algorithm to calculate the checksum of the OpenSBI image and compare it with the checksum carried in the image. If they are inconsistent, an error message is output and the system is reset.

[0017] As a further aspect of the present invention: the privileged management layer completes the privileged mode switching from M-mode to S-mode through a sequence of assembly instructions, including operations on the mstatus register and writing the interrupt vector table address into the mtvec register.

[0018] The OpenSBI boot method for FPGA-based RISC-V SoCs, using the system described above, includes the following steps:

[0019] Step 1: The hardware abstraction layer performs FPGA hardware initialization, implements RV64IMAFD instruction set extension, five-stage pipeline design, L1 instruction cache and data cache configuration, DDR4 controller design and peripheral interface integration, maps hardware configuration registers to a specific address space and supports 32-bit atomic operations;

[0020] Step 2: During the SPL phase of the bootloader layer, the U-Boot image is loaded from the storage medium via the DMA channel, completing DDR4 memory initialization, CLINT interrupt controller configuration, and page table mapping establishment;

[0021] Step 3: During the U-Boot stage of the boot loading layer, the boot method is selected via the Shell command line, the OpenSBI firmware type is read and loaded into the specified area of ​​memory, and image verification is performed at the same time;

[0022] Step 4: Configure the RISC-V registers, enable interrupts, and initialize relevant units in the OpenSBI of the privileged management layer to achieve privileged mode switching from M-mode to S-mode, and perform permission isolation and management;

[0023] Step 5: The kernel execution layer reads the kernel binary image from the storage medium, loads it into the specified memory location through the OpenSBI interface, passes the device tree file information, completes the loading and mounting of the file system, and passes the boot parameters.

[0024] As a further aspect of the present invention: In step 2, the U-Boot image is loaded from the SD card at a rate of 200MB / s during the SPL stage, the DDR4 memory initialization calibrates the DQ / DQS timings through the PHY training sequence, and the page table mapping maps the 0x8000_0000-0xFFFF_FFFF address space to physical memory.

[0025] As a further aspect of the present invention: In step 3, the U-Boot stage supports booting from SD card, NAND flash memory or network, and selects a secure boot version or a standard version through a dynamic firmware version management mechanism. The secure boot version includes RSA-4096 signature verification.

[0026] As a further aspect of the present invention: In step 4, the RISC-V CPU is initially set to run in M-mode in the OpenSBI initial state. When switching to S-mode, the interrupt vector table address is set so that the mtvec register points to the S-mode interrupt handler. M-mode retains control over hardware resources, while S-mode is responsible for managing the operating system kernel.

[0027] As a further aspect of the present invention: In step 5, the kernel image loaded by the kernel execution layer supports the ELF format, the loaded device tree file is a dtb file generated by DTC compilation, the kernel image and device tree file are loaded through the load_image() interface of OpenSBI, and the boot parameters are passed through the jump_to_kernel() interface.

[0028] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0029] 1. Layered initialization mechanism: Through the layered design of FPGA hardware initialization, SPL / U-Boot firmware loading, OpenSBI privileged mode configuration, and kernel startup, the startup process is modularly managed, reducing system coupling;

[0030] 2. Compatibility and scalability: Supports multiple storage media (SD card, NAND flash memory) and operating system types, and implements hardware abstraction through the OpenSBI standard interface, which facilitates the subsequent expansion of new peripherals or upgrade of RISC-V architecture version;

[0031] 3. Enhanced Reliability: Stability during startup is ensured through image verification (CRC32), memory testing (DDR self-refresh), and interrupt-based initialization; a privileged mode layered design prevents unauthorized access to hardware resources by user programs, enhancing system security; and Sv39 virtual address translation (48-bit virtual address space, supported by 56TB of physical memory) restricts user-space programs to the address range of 0x0000_0000-0x7FFF_FFFF, prohibiting access to kernel space (above 0x8000_0000), effectively preventing buffer overflows.

[0032] 4. Optimized development efficiency: The standardized boot process reduces the workload of hardware and firmware adaptation. The interactive interface provided by U-BootShell supports dynamic configuration of boot parameters, which facilitates debugging and rapid iterative development. Attached Figure Description

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

[0034] Figure 1 A schematic diagram of the architecture of the OpenSBI boot system based on FPGA RISC-V SoC provided by the present invention;

[0035] Figure 2 This is a flowchart illustrating the key components and functional implementation of the present invention. Detailed Implementation

[0036] The technical solution of the present invention will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0037] The present invention will be further explained below with reference to specific embodiments.

[0038] Please see Figure 1 and Figure 2 The OpenSBI boot system based on FPGA RISC-V SoC provided in this embodiment of the invention includes a hardware abstraction layer, a bootloader layer, a privilege management layer, and a kernel execution layer. Each layer achieves data interaction and process connection through standardized interfaces.

[0039] In this embodiment, the functions of the hardware abstraction layer, bootloader layer, privilege management layer, and kernel execution layer are implemented as follows:

[0040] (1) Hardware Abstraction Layer

[0041] Instruction set and pipeline optimization:

[0042] Implement the RV64IMAFD instruction set extension, design a five-stage pipeline (fetch, decode, execute, memory access, write back) to improve instruction execution efficiency, support the branch target buffer (BTB) and branch history table (BHT), design L1 instruction cache and data cache (such as a 16KB / way associative structure) to reduce main memory access latency, support virtual address to physical address translation, implement a paging mechanism (such as a 4KB page size), and implement memory protection in conjunction with privileged mode.

[0043] A DDR4 controller (supporting a data rate of 3200MT / s) is designed based on the AXI4-Stream protocol. It connects to peripherals such as the interrupt controller (CLINT / Mtimer) and GPIO controller via the APB bus to achieve high-speed data interaction with external dynamic memory. It integrates common peripheral interfaces such as UART, GPIO, SPI, and SD card controller, and supports debugging interfaces (such as JTAG) for program debugging. Hardware configuration registers (such as the clock frequency register CLK_CFG[31:0]) are mapped to the 0x1000_0000-0x100F_FFFF address space, supporting 32-bit atomic operations.

[0044] (2) Bootloader layer

[0045] SPL Phase (First Phase Bootloader):

[0046] The U-Boot image is embedded in the FPGA's on-chip ROM (512KB space) and loaded from the SD card at a rate of 200MB / s via a DMA channel (AXI-DMA controller). The following key operations are implemented:

[0047] a. Initialize DDR4 memory (calibrate DQ / DQS timings using PHY training sequence);

[0048] b. Configure the CLINT interrupt controller (set the inter-core interrupt IPI queue depth to 16);

[0049] c. Establish page table mapping (map the address space 0x8000_0000-0xFFFF_FFFF to physical memory).

[0050] U-Boot Phase (Second Phase Boot Program):

[0051] A shell command line is provided via the UART interface, allowing users to choose the boot method (such as booting from SD card, NAND flash memory or network).

[0052] Depending on the hardware configuration, the OpenSBI firmware type (fw_dynamic.bin, fw_jump.bin, or fw_pyload.bin) in the boot medium is read and loaded into a specified area of ​​memory (e.g., 0x80200000).

[0053] Through dynamic firmware version management mechanisms, command-line interfaces (such as load_opensbi) are used. <version>Select either the Secure Boot version (with RSA-4096 signature verification) or the standard version. Implement the image verification process:

[0054] uint32_tcrc32_checksum=crc32(0L,ZERO,opensbi_image.size);

[0055] if(crc32_checksum!=opensbi_image.crc32){

[0056] printf("Image verification failed!\n");

[0057] reset_system();

[0058] }

[0059] (3) Privileged Management

[0060] a. Configure RISC-V registers (such as mstatus, mepc, mtvec) and enable interrupts (set the mie register).

[0061] b. Initialize the floating-point unit (FPU) and compressed instruction unit (if supporting RV32GC architecture), and dynamically activate extended functions according to hardware configuration.

[0062] c. Initial state: The RISC-V CPU runs in machine mode (M-mode) and has the highest privileges;

[0063] d. Switching Procedure: The current privileged mode is switched to supervisor mode (S-mode) via OpenSBI's mstatus register operation, and the interrupt vector table address is set (the mtvec register points to the S-mode interrupt handler). The safe switch from M-mode to S-mode is completed using the following assembly instruction sequence:

[0064] csrrw x10,mstatus,x0

[0065] ori x10,x10,0x8000

[0066] csrw mstatus,x10

[0067] la x11,s_mode_vector_table

[0068] csrw mtvec,x11

[0069] e. Privilege isolation: M-mode retains control over hardware resources (such as MMU and clock controller), while S-mode is responsible for managing the operating system kernel, thus implementing privilege level layering.

[0070] platform_init: Completes platform-level initialization (such as timer calibration, peripheral base address mapping);

[0071] ipi_send: Implements inter-processor interrupt (IPI) to support communication in multi-core systems;

[0072] console_putchar: Provides console character output functionality, used to enable log printing.

[0073] (4) Kernel execution layer

[0074] Read the kernel binary image (e.g., Image.gz) from the storage medium (e.g., SD card partition 1), decompress it through the load_image interface provided by OpenSBI and load it into a specified memory location (e.g., 0x81000000), and support the transfer of hardware configuration information from the device tree file (e.g., dtb file).

[0075] If a memory file system (such as initramfs) is used, the file system image (such as initramfs.cpio.gz) is loaded into memory (such as 0x82000000).

[0076] If a block device file system (such as EXT4) is used, the block device driver (such as the SD card controller) is initialized through OpenSBI, and the file system on the storage medium is mounted to the kernel virtual file system (VFS).

[0077] Then, the kernel image (supporting ELF format) and device tree file (dtb file generated by DTC compilation) are loaded through the OpenSBI standard interface load_image(), and the boot parameters (such as root file system path root= / dev / mmcblk0p2) are passed through the jump_to_kernel() interface.

[0078] Please see Figure 1 and Figure 2 The OpenSBI boot method for FPGA-based RISC-V SoC provided in this embodiment of the invention uses the system described above, and the method includes the following steps:

[0079] Step 1: The hardware abstraction layer performs FPGA hardware initialization, implements RV64IMAFD instruction set extension, five-stage pipeline design, L1 instruction cache and data cache configuration, DDR4 controller design and peripheral interface integration, maps hardware configuration registers to a specific address space and supports 32-bit atomic operations;

[0080] Step 2: During the SPL phase of the bootloader layer, the U-Boot image is loaded from the storage medium via the DMA channel, completing DDR4 memory initialization, CLINT interrupt controller configuration, and page table mapping establishment;

[0081] Step 3: During the U-Boot stage of the boot loading layer, the boot method is selected via the Shell command line, the OpenSBI firmware type is read and loaded into the specified area of ​​memory, and image verification is performed at the same time;

[0082] Step 4: Configure the RISC-V registers, enable interrupts, and initialize relevant units in the OpenSBI of the privileged management layer to achieve privileged mode switching from M-mode to S-mode, and perform permission isolation and management;

[0083] Step 5: The kernel execution layer reads the kernel binary image from the storage medium, loads it into the specified memory location through the OpenSBI interface, passes the device tree file information, completes the loading and mounting of the file system, and passes the boot parameters.

[0084] In this embodiment, in step 2, the U-Boot image is loaded from the SD card at a rate of 200MB / s during the SPL stage, the DDR4 memory initialization calibrates the DQ / DQS timings through the PHY training sequence, and the page table mapping maps the 0x8000_0000-0xFFFF_FFFF address space to physical memory.

[0085] In step 3, the U-Boot stage supports booting from SD card, NAND flash memory or network. It selects a secure boot version or a standard version through a dynamic firmware version management mechanism. The secure boot version includes RSA-4096 signature verification.

[0086] In step 4, OpenSBI initially sets the RISC-V CPU to run in M-mode. When switching to S-mode, it sets the interrupt vector table address and makes the mtvec register point to the S-mode interrupt handler. M-mode retains control over hardware resources, while S-mode is responsible for managing the operating system kernel.

[0087] In step 5, the kernel image loaded by the kernel execution layer supports the ELF format, and the loaded device tree file is a dtb file generated by DTC compilation. The kernel image and device tree file are loaded through the OpenSBI load_image() interface, and the boot parameters are passed through the jump_to_kernel() interface.

[0088] In summary, this invention achieves modular management of the boot process through a layered design of FPGA hardware initialization, SPL / U-Boot firmware loading, OpenSBI privileged mode configuration, and kernel startup. This reduces system coupling, supports multiple storage media (SD card, NAND flash memory) and operating system types, and implements hardware abstraction through the OpenSBI standard interface, facilitating subsequent expansion of new peripherals or upgrades to RISC-V architecture versions. Image verification (CRC32), memory testing (DDR self-refresh), and interrupt mechanism initialization ensure the stability of the boot process. The privileged mode layered design prevents unauthorized access to hardware resources by user programs, enhancing system security. Through Sv39 virtual address translation (48-bit virtual address space, 56TB physical memory support), user space programs are restricted to the address range of 0x0000_0000-0x7FFF_FFFF, prohibiting access to kernel space (above 0x8000_0000), effectively preventing buffer overflows. The standardized boot process reduces the workload of hardware and firmware adaptation, and the interactive interface provided by U-Boot Shell supports dynamic configuration of boot parameters, facilitating debugging and rapid iterative development.

[0089] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.< / version>

Claims

1. An OpenSBI boot system based on an FPGA-based RISC-V SoC, characterized in that, It includes a hardware abstraction layer, a bootloader layer, a privilege management layer, and a kernel execution layer. Each layer achieves data interaction and process connection through standardized interfaces. The hardware abstraction layer is used to implement the hardware initialization of the FPGA, including RV64IMAFD instruction set extension, five-stage pipeline design, L1 instruction cache and data cache configuration, DDR4 controller design and peripheral interface integration, mapping hardware configuration registers to a specific address space and supporting 32-bit atomic operations. The bootloader layer includes an SPL stage and a U-Boot stage. The SPL stage is embedded in the FPGA on-chip ROM, loads the U-Boot image from the storage medium through the DMA channel, and completes DDR4 memory initialization, CLINT interrupt controller configuration, and page table mapping establishment. The U-Boot stage provides a Shell command line through the UART interface to select the boot mode, reads the OpenSBI firmware type and loads it into a specified area of ​​memory, and performs image verification. The privileged management layer is OpenSBI, which is used to configure RISC-V registers, enable interrupts, initialize floating-point units and compressed instruction units, realize privileged mode switching from M-mode to S-mode, and realize permission isolation and management through platform-level initialization, inter-processor interrupts and console character output functions. The kernel execution layer is used to read the kernel binary image from the storage medium, load it into a specified memory location through the interface provided by OpenSBI, support the transfer of hardware configuration information through device tree files, as well as the loading and mounting of memory file systems or block device file systems, and the transfer of boot parameters.

2. The OpenSBI boot system based on FPGA and RISC-V SoC according to claim 1, characterized in that, The DDR4 controller in the hardware abstraction layer is designed based on the AXI4-Stream protocol, supports a data rate of 3200MT / s, and is connected to the interrupt controller and GPIO controller peripherals via the APB bus. The integrated peripheral interfaces include UART, GPIO, SPI, SD card controller and JTAG debugging interface.

3. The OpenSBI boot system based on FPGA and RISC-V SoC according to claim 1, characterized in that, In the SPL stage of the bootloader layer, DDR4 memory initialization calibrates the DQ / DQS timing through the PHY training sequence, the CLINT interrupt controller configuration sets the inter-core interrupt IPI queue depth to 16, and the page table mapping maps the 0x8000_0000-0xFFFF_FFFF address space to physical memory.

4. The OpenSBI boot system based on FPGA and RISC-V SoC according to claim 1, characterized in that, In the U-Boot stage of the bootloader layer, the image verification uses the CRC32 algorithm to calculate the checksum of the OpenSBI image and compare it with the checksum carried in the image. If they do not match, an error message is output and the system is reset.

5. The OpenSBI boot system based on FPGA and RISC-V SoC according to claim 1, characterized in that, The privileged management layer completes the privileged mode switching from M-mode to S-mode through a sequence of assembly instructions, including operations on the mstatus register and writing the interrupt vector table address into the mtvec register.

6. An OpenSBI boot method for FPGA-based RISC-V SoC, employing the system described in any one of claims 1-5, characterized in that, The method includes the following steps: Step 1: The hardware abstraction layer performs FPGA hardware initialization, implements RV64IMAFD instruction set extension, five-stage pipeline design, L1 instruction cache and data cache configuration, DDR4 controller design and peripheral interface integration, maps hardware configuration registers to a specific address space and supports 32-bit atomic operations; Step 2: During the SPL phase of the bootloader layer, the U-Boot image is loaded from the storage medium via the DMA channel, completing DDR4 memory initialization, CLINT interrupt controller configuration, and page table mapping establishment; Step 3: During the U-Boot stage of the boot loading layer, the boot method is selected via the Shell command line, the OpenSBI firmware type is read and loaded into the specified area of ​​memory, and image verification is performed at the same time; Step 4: Configure the RISC-V registers, enable interrupts, and initialize relevant units in the OpenSBI of the privileged management layer to achieve privileged mode switching from M-mode to S-mode, and perform permission isolation and management; Step 5: The kernel execution layer reads the kernel binary image from the storage medium, loads it into the specified memory location through the OpenSBI interface, passes the device tree file information, completes the loading and mounting of the file system, and passes the boot parameters.

7. The OpenSBI boot method for FPGA-based RISC-V SoC according to claim 6, characterized in that, In step 2, the SPL stage loads the U-Boot image from the SD card at a rate of 200MB / s, the DDR4 memory initialization calibrates the DQ / DQS timings through the PHY training sequence, and the page table mapping maps the 0x8000_0000-0xFFFF_FFFF address space to physical memory.

8. The OpenSBI boot method for FPGA-based RISC-V SoC according to claim 6, characterized in that, In step 3, the U-Boot stage supports booting from SD card, NAND flash memory or network. It selects a secure boot version or a standard version through a dynamic firmware version management mechanism. The secure boot version includes RSA-4096 signature verification.

9. The OpenSBI boot method for FPGA-based RISC-V SoC according to claim 6, characterized in that, In step 4, OpenSBI initially sets the RISC-V CPU to run in M-mode. When switching to S-mode, it sets the interrupt vector table address and makes the mtvec register point to the S-mode interrupt handler. M-mode retains control over hardware resources, while S-mode is responsible for managing the operating system kernel.

10. The OpenSBI boot method for FPGA-based RISC-V SoC according to claim 6, characterized in that, In step 5, the kernel image loaded by the kernel execution layer supports the ELF format, and the loaded device tree file is a dtb file generated by DTC compilation. The kernel image and device tree file are loaded through the OpenSBI load_image() interface, and the boot parameters are passed through the jump_to_kernel() interface.

Images