rCore Series Notebook

建设中

清华大学操作系统2022-课程笔记，以及以一些相关资源工具的学习补充。

关于 rCore 和清华大学操作系统课程

rCore 是清华大学计算机系开发的一个开源操作系统内核学习项目，基于 Rust 语言，旨在让学生从底层理解操作系统的结构与设计。该项目伴随清华大学的操作系统课程，内容覆盖了从基本操作系统理论到实践的各个方面。

课程目录

• 第零章：实验环境配置

• 第一章：应用程序与基本执行环境

• 第三章：多道程序与分时多任务

• 第四章：地址空间

• 第五章：进程及进程管理

• 第六章：文件系统与 I/O 重定向

• 第七章：进程间通信

• 第八章：并发

更多资源

在学习过程中，我将分享一些翻译的资料与额外的资源，帮助你更好地理解 rCore 和操作系统课程中的内容。如果你对某些部分有疑问或者需要更详细的补充，可以随时在下面评论。

0. 开始前的阅读

An Introduction to RISC-V Boot Flow

本讲座由Atish Patra和Anup Patel主讲，主要讲解了RISC-V体系结构的启动流程。RISC-V是一种开源指令集架构，其灵活性和模块化设计使其在嵌入式系统和高性能计算领域日益受到关注。此文档针对RISC-V启动流程，介绍了它在嵌入式系统中的应用、与传统体系的对比、当前发展状态，以及未来可能的工作方向。

原始内容来源：

幻灯片标题：An Introduction to RISC-V Boot Flow

原作者：Atish Patra, Anup Patel

出处：Western Digital

原始发布日期：2019年12月19日

版权声明：该幻灯片及其内容的版权归Western Digital公司所有。翻译与讲解仅供学习和参考，更多详细信息请参见原文链接。

本文是2019年12月的一个讲座内容，虽然其中的部分技术进展和版本信息已经有些过时，但本文的学习重点在于了解RISC-V启动流程（RISC-V Boot Flow）的基本原理和结构。随着RISC-V生态系统的快速发展，某些工具和固件可能已经更新，因此不必对具体的版本和实现细节深究。阅读本文的目的在于掌握启动流程的整体框架和概念，了解RISC-V如何从上电到操作系统启动的过程，这对未来进一步研究和开发仍然有重要的参考价值。

简单看看即可，重点在于理解基本原理。

Outline

本次介绍的内容包括以下几个方面：

• Common embedded boot flow：介绍常见的嵌入式系统启动流程，帮助读者了解嵌入式系统在启动过程中涉及的关键步骤和组件。
• Current RISC-V boot flow：对RISC-V目前的启动流程进行详细解释，特别是在RISC-V架构上如何实现启动流程，区别于其他常见架构的启动过程。
• OpenSBI Project：深入讲解OpenSBI项目，作为RISC-V系统启动的一个关键组件，它的工作原理及如何在RISC-V启动过程中发挥作用。
• Tutorials：为读者提供关于RISC-V启动的实际操作教程，帮助其在真实环境中应用所学内容。
• Current Status：讲述RISC-V启动流程的当前状态，包括目前的进展、已解决的问题和仍存在的挑战。
• Future work：展望RISC-V启动流程未来的发展方向，探讨可能的改进和新的技术发展。
• Tutorials：再次提供相关的教程链接，帮助用户更深入理解和实践。

Prerequisite

在进行本次学习之前，需要做一些准备工作：

• 下载演示文稿：用户可以通过提供的短链接（shorturl.at/clITU）下载完整的演示文档。

• 操作系统要求：需要一台运行Linux操作系统的设备，任何发行版均可接受。这是因为RISC-V相关的开发环境多基于Linux。

• 可选的内核源代码构建环境：可以选择设置Linux内核源代码的构建环境，这对深入研究和开发RISC-V启动流程非常有帮助。

• Ubuntu用户的具体指令：对于使用Ubuntu操作系统的用户，提供了安装相关开发环境的软件包命令：

  sudo apt-get install git build-essential kernel-package fakeroot libncurses5-dev libssl-dev bison flex
  

  这条命令会安装一系列工具，包括构建工具链、内核打包工具、SSL库开发包等，这些都是在构建、调试和运行RISC-V启动流程时可能需要的依赖项。

Getting started

开始RISC-V的启动流程实验，需要完成以下几步准备工作：

1. 创建工作目录
   使用以下命令创建一个新的目录，并进入该目录：

   mkdir summit_demo; cd summit_demo
   

2. 下载交叉编译工具链
   RISC-V的开发通常需要使用交叉编译工具链来编译代码，工具链可从以下链接下载：

   https://toolchains.bootlin.com/releases_riscv64.html

3. 下载预构建的镜像
   预先构建好的RISC-V镜像文件可以从以下链接获取：

   https://wdc.box.com/s/ihywc2xap5m4mflyingjtndf0sy62zha3

4. 克隆OpenSBI项目
   使用Git将OpenSBI项目克隆到本地，OpenSBI是RISC-V启动流程中重要的部分：

   git clone https://github.com/riscv/opensbi.git
   

5. 克隆U-Boot项目
   同样，使用Git克隆U-Boot项目并切换到指定版本（v2019.10）。U-Boot是一个通用的引导加载程序，广泛用于嵌入式系统中：

   git clone https://github.com/u-boot/u-boot.git; git checkout v2019.10
   

这些步骤将为RISC-V启动实验设置好基础的开发环境和工具链，确保可以顺利运行后续的启动过程。

Common boot flow

在嵌入式系统中，启动过程通常分为多个阶段，每个阶段的功能和执行环境不同。常见的启动流程包括以下几个阶段：

1. ROM阶段

   • 运行环境：从片上ROM（Read-Only Memory）中执行。
   • 功能：负责系统上电和时钟设置，SOC（系统级芯片）的启动。
   • 该阶段的软件直接存储在芯片中，执行非常基础的启动任务，为后续阶段的运行做准备。

2. LOADER阶段

   • 运行环境：通常从片上SRAM（Static RAM）中运行，有时也会初始化DDR内存。
   • 功能：加载运行时环境（RUNTIME）和引导加载程序（BOOTLOADER）。
   • 示例：BIOS/UEFI、U-Boot SPL、Coreboot。
     在这一阶段，系统开始对内存进行初始化，加载更复杂的启动代码，准备进入运行时阶段。

3. RUNTIME阶段

   • 运行环境：可以从片上SRAM或已初始化的DDR内存中执行。
   • 功能：处理SOC的安全设置，提供符合规格的运行时服务。
   • 示例：ATF（Arm Trusted Firmware）、BIOS/UEFI。
     该阶段开始执行系统的安全设置，并确保系统的关键资源按照设计规格被正确管理。

4. BOOTLOADER阶段

   • 运行环境：从DDR内存中运行，通常为开源软件。
   • 功能：文件系统支持、网络启动、引导配置等。
   • 示例：U-Boot、GRUB、LinuxBoot。
     引导加载程序负责加载操作系统内核，提供网络启动等功能，并引导进入最终的操作系统。

5. OS阶段
   在引导加载程序的引导下，操作系统（OS）被加载并开始执行，系统正式进入工作状态。

整个流程通过不同阶段的加载和跳转，逐步引导系统从最初的硬件上电状态进入功能完善的操作系统，确保了启动过程的安全性和稳定性。

Common boot flow in ARM64

在ARM64架构中，启动流程也分为多个阶段，常见的启动模型如下：

1. ROM阶段

   • 功能：从片上ROM中运行，负责启动系统最初的硬件初始化。通常，它会加载下一个阶段的启动加载程序，例如Coreboot或U-Boot SPL（Secondary Program Loader）。

2. Coreboot/U-Boot SPL / ATF BL2阶段

   • 功能：从ROM加载，负责初始化系统内存（如DDR）和其他关键硬件资源。对于某些系统，还会加载ATF（Arm Trusted Firmware）BL2，它处理一些系统安全和电源管理任务。

3. ATF BL31阶段

   • 功能：这是ATF的一个关键部分，负责处理安全性问题，例如设置安全世界与非安全世界之间的隔离。它在系统进入U-Boot或操作系统之前，确保所有的安全配置和硬件初始化已经完成。

4. U-Boot阶段

   • 功能：U-Boot作为引导加载程序，负责加载操作系统内核。它可能会使用"Falcon模式"来直接加载操作系统，跳过某些额外的初始化步骤，以加快启动速度。

5. OS阶段

   • 功能：操作系统加载并开始运行。ARM64平台通常使用Linux等操作系统。

这个启动流程中，ATF（Arm Trusted Firmware）是ARM64平台的一个重要部分，负责处理安全模式的切换和运行时的硬件管理。整个流程从硬件初始化开始，经过多次加载和跳转，最终将系统引导至操作系统。

RISC-V Upstream Boot Flow

与ARM64相似，RISC-V的启动流程也遵循多个阶段的模型，以下是RISC-V的启动流程：

1. ZSBL阶段 (M-mode, ROM)

   • 功能：ZSBL（Zero Stage Boot Loader）是启动的第一个阶段，从片上ROM运行，负责最基础的硬件初始化任务。它会加载FSBL（First Stage Boot Loader）。

2. FSBL阶段 (M-mode, LOADER)

   • 功能：FSBL从ZSBL加载，进一步初始化内存和其他外设资源。对于SiFive开发的RISC-V平台，FSBL是特定的加载程序，不过在其他平台上可能会被Coreboot或U-Boot SPL取代。

3. OpenSBI阶段 (M-mode, RUNTIME)

   • 功能：OpenSBI（Open Source Supervisor Binary Interface）是RISC-V架构中的一个关键组件，它为上层软件提供RISC-V特定的运行时服务。OpenSBI运行在机器模式（M-mode）下，直接控制硬件，并提供标准化的接口给下一阶段的引导加载程序或操作系统。

4. U-Boot阶段 (S-mode, BOOTLOADER)

   • 功能：U-Boot在S-mode（Supervisor Mode）下运行，作为引导加载程序，负责加载操作系统内核。U-Boot在此阶段的作用与其他架构相似，处理网络启动、存储设备管理和文件系统加载。

5. Linux阶段 (S-mode, OS)

   • 功能：最终操作系统被加载并进入运行。RISC-V目前主要支持Linux等开源操作系统。

关键说明

• 适用平台：这个流程主要适用于HiFive Unleashed硬件平台，这是目前 (2019.12) 唯一支持Linux的RISC-V开发板。
• 使用U-Boot作为最后阶段的引导加载程序：U-Boot是一个通用的引导加载程序，处理操作系统的加载。
• OpenSBI：这是RISC-V的特定组件，负责为引导加载程序和操作系统提供运行时服务。

与ARM64的启动流程相比，RISC-V的启动流程同样分为多个阶段，但其中的OpenSBI是RISC-V独有的一个关键部分。它提供了机器模式（M-mode）下的关键服务，使得引导加载程序和操作系统可以在RISC-V平台上顺利运行。

RISC-V boot flow development timeline

RISC-V启动流程的发展历程 (-2019.12) 展现了该架构的逐步成熟和演变。每个重要的里程碑标志着RISC-V启动流程支持的新功能和特性：

1. Legacy（Feb 18）
   在2018年2月之前，RISC-V启动流程仍处于早期阶段，很多现代启动组件尚未完善。

2. Grub support（Nov 18）
   2018年11月，RISC-V得到了Grub（Grand Unified Bootloader）的支持。Grub是一个常用的开源引导加载程序，它为RISC-V引入了更通用的启动加载选项，支持多种操作系统。

3. OpenSBI v0.1 release（Jan 19）
   2019年1月，OpenSBI v0.1版本发布。OpenSBI是RISC-V启动流程中的关键组件，为操作系统提供运行时服务并管理硬件资源。

4. U-Boot support for Unleashed（Feb 19）
   2019年2月，U-Boot引入了对HiFive Unleashed开发板的支持。这是RISC-V平台上首个支持Linux的开发板，U-Boot的支持使得该平台能够顺利引导操作系统。

5. U-Boot SMP support（Mar 19）
   2019年3月，U-Boot增加了SMP（对称多处理）支持，允许多核处理器在RISC-V平台上进行并行处理，提升系统的性能和灵活性。

6. U-Boot MMC support（July 19）
   2019年7月，U-Boot引入了对MMC（多媒体卡）的支持，允许RISC-V设备通过MMC卡存储和加载操作系统。

7. U-Boot SPL（July 19）
   同样在2019年7月，U-Boot SPL（Secondary Program Loader）支持引入。SPL是一种轻量级引导程序，专门用于初始化内存和加载完整的引导程序。

8. Coreboot（Aug 19）
   2019年8月，Coreboot支持被引入RISC-V启动流程。Coreboot是一个快速、灵活的开源固件平台，旨在替代传统的BIOS/UEFI。

9. EDK2（Oct 19）
   2019年10月，EDK2的支持被加入。EDK2是UEFI固件的开源实现，它为RISC-V提供了标准化的固件接口，使其能够与更广泛的软件生态系统兼容。

这条时间线展示了RISC-V启动流程逐步从基础的启动支持走向复杂的多处理器支持、高级存储设备支持和开源固件的集成，最终形成一个功能完善、模块化的启动系统。

What is SBI?

SBI（Supervisor Binary Interface）是RISC-V架构中的管理模式二进制接口，其作用类似于系统调用接口，允许超级模式（S-mode）的操作系统与机器模式（M-mode）的执行环境（SEE, Supervisor Execution Environment）进行通信。它定义了一组标准化的接口，使得不同的操作系统和平台可以在不重复编写硬件相关代码的情况下，访问底层硬件资源。

SEE的定义

• M-mode下的运行时固件：为运行在HS-mode（Hypervisor Supervisor Mode）的操作系统或虚拟机管理器提供运行时服务。
• HS-mode下的虚拟机管理器：为运行在VS-mode（Virtual Supervisor Mode）的客户操作系统提供管理功能。

SBI的作用

• 减少平台代码的重复：通过统一的接口，减少Linux、FreeBSD等操作系统中的平台特定代码，简化操作系统在不同硬件平台上的移植和维护工作。
• 提供共享驱动程序：使多个平台可以共享驱动程序，避免为每个平台单独编写。
• 提供硬件资源访问接口：SBI允许操作系统直接访问机器模式下（M-mode）的硬件资源。

规范和开发进展

SBI的规范由Unix平台规范工作组制定，当前的版本包括：

• SBI v0.1：目前 (2019.12) 广泛使用。
• SBI v0.2：正在草案阶段，旨在提供更多功能和更好的性能。

SBI的详细文档和规范可以通过RISC-V的SBI GitHub项目获取。

What is OpenSBI?

OpenSBI是RISC-V体系结构中Supervisor Binary Interface (SBI) 规范的开源实现。它为机器模式（M-mode）提供运行时服务，是RISC-V启动流程中的关键组件，通常在ROM/LOADER阶段之后使用。OpenSBI通过提供标准化接口，使得上层操作系统可以与硬件进行交互，从而避免了SBI实现的碎片化。

OpenSBI的主要特性

• 开源实现：OpenSBI遵循BSD-2条款许可证，由社区维护和开发。它确保SBI的实现一致性，并避免不同平台上SBI实现的差异。
• 提供运行时服务：OpenSBI在机器模式（M-mode）下运行，负责为操作系统（通常是在超级模式S-mode下运行）提供必要的服务。
• 支持参考平台：OpenSBI为不同平台提供了参考驱动程序，包括PLIC（平台级中断控制器）、CLINT（核心本地中断器）和UART 8250驱动程序等。其他平台可以基于这些通用代码添加自己的平台驱动程序。
• 社区维护的开源项目：用户可以通过OpenSBI的GitHub获取源代码、文档以及最新的更新。

OpenSBI的作用

OpenSBI主要为RISC-V平台提供一个标准化的接口，使操作系统可以高效、安全地与硬件交互。它被设计为可移植和模块化的，使得不同硬件平台可以复用它的核心功能，同时添加各自平台特定的驱动程序。

Key Features

OpenSBI具备以下几个重要的功能特性，确保其能够在广泛的硬件环境中高效运行，并适应不同的使用场景：

分层结构以适应多种用例

• 通用SBI库与平台抽象层：
  通用的SBI库实现了平台抽象，通常与外部固件和引导加载程序（如EDK2、Secure Boot工作组实现的UEFI）一起使用。它提供了标准的SBI接口，使得外部引导加载程序可以在不同的平台上稳定运行。

• 平台特定的库：
  与核心库类似，但包含特定平台的驱动程序。它允许硬件厂商根据自身硬件的特点进行定制，而不影响SBI核心功能的通用性。

• 平台特定的参考固件：
  提供三种不同类型的运行时固件，供开发人员参考和使用。它们涵盖了从最基本的引导流程到高级的硬件初始化需求。

广泛支持的硬件特性

OpenSBI支持多种硬件特性，确保它能够在各种不同的RISC-V系统中运行，包括：

• 支持RV32和RV64：既支持32位的RISC-V架构，也支持64位架构，使其在不同的硬件平台上都可以使用。
• 虚拟化支持：支持Hypervisor模式，允许虚拟机管理程序在硬件上运行多个操作系统实例。
• 未对齐的加载/存储处理：处理未对齐的内存访问操作，确保在所有情况下都能正确处理数据。
• CSR（控制状态寄存器）仿真：为某些平台提供CSR仿真，确保它们能够顺利运行RISC-V的通用指令集。
• 使用PMP（物理内存保护）保护固件：通过PMP确保固件在运行时免受非法内存访问的威胁，增强系统的安全性。

OpenSBI的层次结构设计和其支持的硬件特性使其能够适应从简单到复杂的各种RISC-V平台，成为RISC-V生态系统中不可或缺的一部分。通过提供标准化的接口和驱动支持，OpenSBI确保了RISC-V平台的可移植性和扩展性。

Platform support

OpenSBI支持多种RISC-V平台，包括以下几种：

• SiFive HiFive Unleashed：这是RISC-V开发板中最为著名的硬件平台之一，支持Linux操作系统运行。
• Andes AE350：由Andes Technology开发的RISC-V处理器平台，适用于嵌入式系统和IoT应用。
• Ariane FPGA SoC：基于Ariane RISC-V内核的可编程逻辑器件（FPGA）系统芯片，适合硬件验证和研究。
• Kendryte K210：一个专为物联网和AI应用设计的RISC-V芯片，内置AI加速器和神经网络处理器。
• QEMU虚拟机（32位/64位）：QEMU是一款开源虚拟机仿真器，可以通过模拟RISC-V架构的虚拟机进行开发和测试，支持32位和64位系统。
• OmniXtend：一个支持RISC-V的开源互连协议，用于高性能计算和数据中心应用。

这些平台覆盖了从硬件开发板到虚拟机环境的广泛应用场景，能够帮助开发者在不同的硬件和虚拟化环境中进行RISC-V软件开发和测试。

Tutorial

Setup details

为了成功设置RISC-V开发环境，以下步骤详细说明了如何配置工具链、QEMU仿真器以及环境变量。

1. 查看当前工作目录的设置
   运行以下命令查看当前目录下的文件和设置：

   ls -l
   

   

   输出结果展示了几个关键文件：

   • linux_Image：Linux内核镜像文件。
   • linux_rootfs.img：根文件系统镜像，用于仿真系统的文件结构和内容。
   • opensbi：OpenSBI的二进制文件，提供运行时服务。
   • qemu-system-riscv64：QEMU的RISC-V 64位二进制文件，用于虚拟机仿真。
   • riscv64--glibc--bleeding-edge-2018.11-1：RISC-V的交叉编译工具链。
   • u-boot：U-Boot引导加载程序，用于启动系统。

2. 解压工具链并将其添加到环境路径
   下载并解压RISC-V工具链后，需要将其路径添加到系统环境变量中：

   tar -xvf riscv64--glibc--bleeding-edge-2018.11-1.tar.bz2
   export PATH=$PATH:riscv64--glibc--bleeding-edge-2018.11-1/bin/
   

   这将确保可以在命令行中直接调用交叉编译工具链进行开发和构建。

3. 更改QEMU二进制文件的权限
   为了能够运行QEMU仿真器，需要为其二进制文件设置执行权限：

   chmod a+x qemu-system-riscv64
   

   这一步确保QEMU仿真器可以被正确执行，用于模拟RISC-V系统。

4. 设置环境变量CROSS_COMPILE和ARCH
   设置交叉编译工具链的相关环境变量，以确保编译过程中可以正确识别目标架构：

   export ARCH=riscv
   export CROSS_COMPILE=riscv64-linux-
   

   这里的ARCH变量指定了目标架构为RISC-V，而CROSS_COMPILE则设置了用于交叉编译的前缀，使得编译器知道要为RISC-V平台生成代码。

通过上述步骤，可以成功配置一个完整的RISC-V开发和仿真环境。这些步骤尤其适合那些希望在虚拟化环境中运行RISC-V操作系统或开发软件的开发者。

Tutorial-I: Boot Linux in Qemu as a payload to OpenSBI

这部分指导如何通过OpenSBI在Qemu中启动Linux系统。Qemu是一个强大的虚拟化工具，支持RISC-V等多种架构，允许用户在虚拟环境中运行完整的操作系统。本教程将详细介绍如何将Linux内核作为OpenSBI的payload，在Qemu中运行RISC-V Linux系统。

1. 编译OpenSBI

首先，进入OpenSBI的源代码目录，并编译适用于Qemu虚拟机的OpenSBI固件。这里的PLATFORM参数指定了编译目标为Qemu的虚拟机平台，FW_PAYLOAD_PATH参数指定了将Linux内核作为OpenSBI的payload（负载）。

cd opensbi; make PLATFORM=qemu/virt FW_PAYLOAD_PATH=../linux_Image; cd ..

这一过程会生成适用于Qemu虚拟机的OpenSBI镜像，之后可以用作引导加载程序，将Linux内核作为payload。

2. 在Qemu中运行OpenSBI和Linux

接下来，通过Qemu运行OpenSBI，并将Linux根文件系统和内核加载到虚拟机中。以下是用于启动Qemu的命令，其中包括各个参数的具体含义：

qemu-system-riscv64 -M virt -m 256M -nographic \
-kernel opensbi/build/platform/qemu/virt/firmware/fw_payload.elf \
-drive file=linux_rootfs.img,format=raw,id=hd0 \
-device virtio-blk-device,drive=hd0 \
-append "root=/dev/vda rw console=ttyS0"

• -M virt：指定Qemu使用的虚拟硬件平台，这里选择的是虚拟机平台。
• -m 256M：分配给虚拟机的内存大小，设定为256MB。
• -nographic：以无图形界面的方式运行虚拟机，所有输出将通过命令行显示。
• -kernel：指定OpenSBI固件的路径，OpenSBI的固件负责引导系统并加载Linux内核。
• -drive：指定根文件系统镜像的路径，这里使用的是linux_rootfs.img，格式为原始镜像。
• -device virtio-blk-device：使用virtio块设备驱动，为Qemu虚拟机提供存储设备支持。
• -append：向Linux内核传递命令行参数，指定根文件系统位于/dev/vda，并设置控制台为ttyS0。

通过上述命令，Qemu将启动虚拟的RISC-V系统，加载OpenSBI并运行Linux内核。

Adding Support for New Platforms

在开发过程中，可能需要为OpenSBI添加对新平台的支持。以下是为新平台添加支持的步骤：

1. 在/platform目录下创建新的平台目录
   为新平台创建一个名为<xyz>的目录，用于存放与该平台相关的配置文件和源码。

2. 创建平台配置文件<xyz>/config.mk
   该文件将包含平台的配置选项、常用驱动程序的标志以及固件选项。可以参考模板platform/template/config.mk创建该文件。

3. 创建平台对象文件<xyz>/objects.mk
   在此文件中列出需要编译的与平台相关的特定对象文件。可以参考platform/template/objects.mk创建该文件。

4. 创建平台源码文件<xyz>/platform.c
   该文件实现与平台相关的具体功能，并提供struct sbi_platform实例。可以参考platform/template/platform.c创建该文件。

额外说明

• 新平台的支持目录<xyz>可以放置在OpenSBI源代码外部，但需要确保其路径在编译时正确指定。

通过这些步骤，开发者可以为OpenSBI添加对新硬件平台的支持，确保其能够在不同的硬件环境中正常运行。

Reference Firmwares

OpenSBI提供了几种类型的参考固件，每种固件都针对特定的平台需求。不同类型的固件适用于RISC-V启动流程中的不同阶段和使用场景。

1. FW_PAYLOAD

• 功能：该固件将下一阶段的引导程序作为负载（payload）进行加载。这是适用于Linux等操作系统的RISC-V硬件上最常用的固件类型。
• 默认使用：在可运行Linux的RISC-V硬件中，FW_PAYLOAD是最常用的参考固件。

2. FW_JUMP

• 功能：该固件带有一个固定的跳转地址，用于跳转到下一个引导阶段。这种方式适用于需要手动指定引导地址的场景。
• 默认使用：这是QEMU仿真环境中的默认引导方法。

3. FW_DYNAMIC

• 功能：该固件通过动态信息来确定下一个引导阶段。这种方式通常用于U-Boot SPL或Coreboot等加载程序，能够根据运行时信息灵活调整引导流程。
• 使用场景：U-Boot SPL和Coreboot等平台使用FW_DYNAMIC来管理引导流程。

SOC厂商的选择

SOC厂商可以根据自身需求选择适合的固件类型：

• 使用OpenSBI的参考固件作为M-mode的运行时固件。
• 使用OpenSBI作为库，完全从头构建M-mode运行时固件。
• 扩展现有的M-mode固件（如U-Boot_M_mode或EDK2），并将OpenSBI作为库来增强功能。

通过这些选项，硬件厂商能够根据平台的实际需求，灵活地选择和定制适合的固件解决方案。

U-Boot: An universal boot loader

U-Boot（Universal Boot Loader）是嵌入式系统中最常用的通用引导加载程序，广泛用于多个架构和平台。它作为最后阶段的引导加载器，负责加载操作系统并管理底层硬件资源。

U-Boot的支持范围

• 支持多种指令集架构（ISA）：包括x86、ARM、AARCH64、RISC-V、ARC等，使其在不同架构的硬件上都能使用。
• 支持多种外设接口：如UART、SPI、I2C、以太网、SD卡、USB等，涵盖了几乎所有常见的嵌入式外设。
• 支持多种文件系统：能够从不同的文件系统中加载镜像，包括常见的文件系统格式。
• 支持多种网络协议：如TFTP等网络协议，允许从网络中加载操作系统镜像或数据。

U-Boot的功能

• 加载镜像：可以从网络、文件系统、可移动设备等多种介质中加载操作系统镜像。
• 命令行管理界面：U-Boot提供了一个简便的命令行接口，用于执行引导命令、配置启动参数以及调试系统。

高度的可定制性

U-Boot具备丰富的定制选项，能够根据实际需求进行裁剪和优化：

• U-Boot SPL：这是U-Boot的精简版本，通常作为启动的第一级引导加载器，用于最小化引导时间并加载完整的U-Boot程序。
• Falcon模式：该模式用于加速启动流程，直接加载操作系统，跳过某些不必要的初始化步骤。

U-Boot凭借其广泛的支持、灵活的定制性以及强大的功能，成为嵌入式系统中几乎标准的引导解决方案。它可以适应从开发板到生产环境的多种场景，使得系统启动流程更加高效和灵活。

Tutorial-II: Boot Linux in Qemu using U-Boot proper

这部分介绍如何在Qemu中通过完整的U-Boot（U-Boot proper）引导Linux系统。与之前的教程不同，这里使用的是U-Boot作为最后阶段的引导加载程序，而不是直接将Linux作为OpenSBI的payload。通过此方法，用户可以充分利用U-Boot的灵活性和强大的引导功能。

1. 编译U-Boot

首先，进入U-Boot的源代码目录，并为RISC-V平台的Qemu环境进行配置和编译。这里使用了qemu-riscv64_smode_defconfig配置文件，它为RISC-V 64位的Qemu虚拟机环境生成适合的U-Boot配置。

cd u-boot; make qemu-riscv64_smode_defconfig; make; cd ..

2. 编译OpenSBI

接下来，进入OpenSBI的源代码目录，并编译适用于Qemu的OpenSBI固件。与之前不同，这次没有指定payload，意味着OpenSBI的职责仅仅是作为U-Boot的引导器。

cd opensbi; make PLATFORM=qemu/virt; cd ..

这里使用fw_jump固件类型，允许U-Boot来加载Linux内核。

3. 在Qemu中运行U-Boot和OpenSBI

编译完成后，可以通过Qemu运行U-Boot和OpenSBI，同时加载Linux内核和根文件系统。运行以下命令：

./qemu-system-riscv64 -M virt -smp 4 -m 256M -nographic \
-bios opensbi/build/platform/qemu/virt/firmware/fw_jump.elf \
-kernel u-boot/u-boot.bin -device loader,file=linux_Image,addr=0x84000000 \
-drive file=linux_rootfs.img,format=raw,id=hd0 \
-device virtio-blk-device,drive=hd0

• -M virt：指定使用Qemu的虚拟机平台。
• -smp 4：为虚拟机分配4个CPU核心，模拟多核环境。
• -m 256M：分配256MB内存。
• -nographic：以无图形界面的方式运行。
• -bios：指定OpenSBI固件路径，此处使用的是fw_jump.elf。
• -kernel：指定U-Boot二进制文件作为引导加载程序。
• -device loader：加载Linux内核，并指定其地址为0x84000000，这是U-Boot期望的内核加载地址。
• -drive：指定根文件系统镜像，格式为原始格式。
• -device virtio-blk-device：使用virtio块设备模拟存储设备。

通过该命令，Qemu将启动虚拟机，加载OpenSBI和U-Boot，并进入U-Boot的命令行界面。

4. 在U-Boot命令行引导Linux

启动后，你将进入U-Boot的命令行提示符。在这里，可以通过以下命令引导Linux内核：

=> setenv bootargs "root=/dev/vda rw console=ttyS0 earlycon=sbi"
=> cp.l ${fdtcontroladdr} ${fdt_addr_r} 0x10000
=> booti ${kernel_addr_r} - ${fdt_addr_r}

• setenv bootargs：设置内核引导参数，这里指定根文件系统为/dev/vda，并配置控制台输出。
• cp.l：复制设备树控制块（fdtcontroladdr）到设备树地址寄存器（fdt_addr_r）。
• booti：引导Linux内核，kernel_addr_r是内核的加载地址，fdt_addr_r是设备树的地址。

执行这些命令后，U-Boot将加载Linux内核并启动系统。

Boot flow using OpenSBI dynamic firmware

在使用OpenSBI动态固件的启动流程中，固件通过动态信息来确定下一个引导阶段。这种方式比固定地址跳转更加灵活，适用于复杂的启动场景。以下是使用OpenSBI动态固件的典型启动流程：

1. ZSBL (M-mode, ROM)
   第一个阶段是从机器模式（M-mode）执行的片上ROM固件，负责最基本的硬件初始化。

2. U-Boot SPL/Coreboot (M-mode)
   第二阶段使用U-Boot SPL或Coreboot，它们在M-mode下运行，并负责加载下一阶段的启动固件。

3. OpenSBI (M-mode, RUNTIME)
   OpenSBI在M-mode下提供运行时服务，使用动态固件（fw_dynamic），通过寄存器a2传递关于下一引导阶段的信息。

4. U-Boot (S-mode, BOOTLOADER)
   OpenSBI引导进入U-Boot，U-Boot运行在超级模式（S-mode）下，负责加载Linux内核。

5. Linux (S-mode, OS)
   最终，U-Boot加载并引导Linux操作系统，进入正式的工作环境。

核心要点

• OpenSBI动态固件通过a2寄存器传递下一引导阶段的地址。
• 支持Coreboot和U-Boot SPL在硬件和QEMU中运行。
• 目前HiFive Unleashed板上尚不支持U-Boot SPL。

Tutorial-III: Boot Linux in Qemu using U-Boot SPL

这部分介绍如何在Qemu中使用U-Boot SPL作为第一阶段的引导加载程序来引导Linux操作系统。U-Boot SPL是U-Boot的简化版本，通常用于初始化系统硬件并加载完整的U-Boot或操作系统。

1. 编译OpenSBI

首先，编译OpenSBI固件，生成适用于Qemu虚拟机的动态固件。与之前不同，这次不指定payload，OpenSBI的职责是加载U-Boot SPL。

cd opensbi; make PLATFORM=qemu/virt; cd ..

这里生成的fw_dynamic.bin固件将用于引导U-Boot SPL。

2. 编译U-Boot SPL

接下来，编译U-Boot SPL。在这个过程中，需要设置CROSS_COMPILE环境变量并指定OpenSBI动态固件的路径。

cd u-boot; export OPENSBI=../opensbi/build/platform/qemu/virt/firmware/fw_dynamic.bin; \
ARCH=riscv CROSS_COMPILE=riscv64-linux- make qemu-riscv64_spl_defconfig; \
ARCH=riscv CROSS_COMPILE=riscv64-linux- make; cd ..

这里使用qemu-riscv64_spl_defconfig配置文件为Qemu生成U-Boot SPL的配置。

3. 在Qemu中运行U-Boot SPL和Linux

使用以下命令在Qemu中运行U-Boot SPL和Linux镜像：

./qemu-system-riscv64 -nographic -machine virt -m 2G -bios u-boot/spl/u-boot-spl \
-kernel u-boot/u-boot.itb -device loader,file=linux_Image,addr=0x86000000 \
-drive file=linux_rootfs.img,format=raw,id=hd0 \
-device virtio-blk-device,drive=hd0

• -machine virt：指定Qemu虚拟机硬件平台。
• -m 2G：为虚拟机分配2GB内存。
• -bios u-boot/spl/u-boot-spl：指定U-Boot SPL的二进制文件路径。
• -kernel u-boot/u-boot.itb：使用FIT镜像（包含U-Boot和设备树）。
• -device loader：加载Linux内核，并指定其地址为0x86000000。
• -drive：指定根文件系统镜像。
• -device virtio-blk-device：使用virtio块设备模拟存储。

通过该命令，Qemu将启动U-Boot SPL，加载U-Boot并引导Linux内核。

4. 在U-Boot命令行引导Linux

当Qemu成功运行后，您将进入U-Boot的命令行界面。在这里，您需要设置引导参数并引导Linux内核：

=> cp.l 0x86000000 ${kernel_addr_r} 0x100000
=> setenv bootargs "root=/dev/vda rw console=ttyS0 earlycon=sbi"
=> cp.l ${fdtcontroladdr} ${fdt_addr_r} 0x10000
=> booti ${kernel_addr_r} - ${fdt_addr_r}

• cp.l 0x86000000 ${kernel_addr_r} 0x100000：将Linux内核从加载地址0x86000000复制到内存中的U-Boot地址空间。
• setenv bootargs：设置内核引导参数，这里指定根文件系统为/dev/vda，并配置控制台输出为ttyS0。
• cp.l ${fdtcontroladdr} ${fdt_addr_r} 0x10000：复制设备树控制块到设备树地址寄存器。
• booti：引导Linux内核，指定内核地址和设备树地址。

执行这些命令后，U-Boot将加载Linux内核并启动系统。

Boot flow using OpenSBI as a library

当OpenSBI作为库使用时，它被集成到外部固件的源代码中。通过这种方式，外部固件可以调用OpenSBI的功能，并作为其启动流程的一部分来执行。在这种模式下，必须确保正确的配置和编译环境，使得OpenSBI能够与外部固件无缝集成。

核心要点

• OpenSBI作为外部固件源代码的一部分：OpenSBI与外部固件紧密集成，外部固件需要调用OpenSBI的API。
• 必须配置程序堆栈和scratch空间：为了确保每个HART（硬件线程）的独立运行，外部固件必须为每个HART配置专属的堆栈和scratch空间。
• 相同的GCC目标选项：外部固件和OpenSBI的源代码必须使用相同的GCC编译选项，例如-march、-mabi和-mcmodel，以保证兼容性。
• EDK2与OpenSBI的集成：目前 (2019.12)，HPE公司正在推动OpenSBI与EDK2的集成。该集成已经适用于U540和Xilinx VC707 FPGA平台，OpenSBI在EDK2的Pre-EFI Initialization (PEI)阶段作为库来使用。

EDK2集成的详细说明

• EDK2 mailing list上已有集成的OpenSBI内容可供参考。
• OpenSBI与EDK2构建环境兼容，并作为PEI阶段的一部分使用。这种集成极大增强了OpenSBI与EDK2固件的合作，尤其在高性能嵌入式系统中使用RISC-V的环境下。

Constraints on using OpenSBI as a Library

当OpenSBI作为外部固件的库使用时，存在一些必须遵守的限制条件和技术要求，以确保正确的运行。

编译选项要求

• 相同的GCC目标选项：必须为外部固件和OpenSBI使用相同的GCC目标编译选项，包括：
  • -march：指定RISC-V指令集架构的版本和扩展。
  • -mabi：定义应用二进制接口（ABI），确保外部固件与OpenSBI之间的函数调用兼容。
  • -mcmodel：指定内存模型，控制生成代码时的内存寻址方式。

外部固件必须为每个HART创建独立的堆栈和scratch空间

• 程序堆栈（Program Stack）：外部固件需要为每个HART配置一个独立的堆栈，避免不同HART之间的堆栈冲突。
• OpenSBI scratch空间：外部固件必须为每个HART设置OpenSBI的scratch空间，通常是通过struct sbi_scratch结构体来实现。

使用OpenSBI函数的约束

调用OpenSBI的函数时，外部固件需要遵守以下限制：

1. MSCRATCH寄存器：必须为每个调用HART将其MSCRATCH寄存器设置为其专属的OpenSBI scratch空间。
2. SP寄存器：调用HART的栈指针（SP）必须设置为该HART的独立堆栈空间，确保各HART之间不会干扰彼此的堆栈。

其他要求

外部固件还必须确保以下条件：

• 中断状态：在调用SBI函数时，必须禁用MSTATUS和MIE寄存器中的中断位，以避免中断干扰函数执行。
• sbi_init()的调用：必须为每个HART在系统启动时或HART热插拔事件中调用sbi_init()，以正确初始化。
• sbi_trap_handler()的调用：当发生机器模式（M-mode）中断或陷阱时，必须调用sbi_trap_handler()，以确保能够正确处理这些异常情况。

Current Status

RISC-V启动生态系统正在快速发展，预计在 (2019) 年末之前将实现完整的传统启动流程支持。以下是当前的进展情况：

OpenSBI

• 积极开发与维护：OpenSBI作为RISC-V架构的关键组件之一，正在被持续开发和维护。
• 版本 0.5 已发布：最新版本具备更完善的功能和优化。
• 默认使用：在多种构建工具中，OpenSBI已经成为默认的BIOS接口，例如Buildroot、Yocto、OpenEmbedded和QEMU BIOS。
• 镜像可用：Fedora和Debian的RISC-V系统镜像已经包含了OpenSBI的二进制文件。

U-Boot

• U-Boot-2019.10 发布：该版本已经完全支持HiFive Unleashed S模式。
• 支持网络和MMC引导：该版本支持通过网络和MMC卡引导操作系统。
• FIT镜像支持：U-Boot支持FIT镜像加载，它包含了内核、设备树、RAM盘等多个组件。
• EFI支持：为RISC-V架构提供了EFI支持，进一步增强了启动灵活性。

Grub

• 上游支持RISC-V：Grub已经在上游版本中提供了对RISC-V的支持，能够加载Linux内核。

Linux Kernel

• 内核主线支持QEMU引导：上游Linux内核可以在QEMU中正常启动。
• 设备树集成：RISC-V的设备树已经集成在Linux内核中，支持多种硬件配置。
• v5.3内核：Linux 5.3版本可以与OpenSBI和U-Boot配合，在HiFive Unleashed板上正常工作。

Future Boot Support

未来，RISC-V的启动支持将进一步扩展，目标是构建一个稳定、易用的启动生态系统。以下是未来的启动支持方向：

EFI Stub支持

• Linux内核中的EFI Stub支持：正在开发中，目标是提供完整的UEFI支持。这将为RISC-V带来企业级的启动环境，确保兼容更多高级功能。

U-Boot SPL 支持 HiFive Unleashed

• HiFive Unleashed的U-Boot SPL支持：正在开发中，未来可以通过SPL引导HiFive Unleashed板的操作系统。

Coreboot中的SMP支持

• 多处理器支持：Coreboot正在开发对SMP（对称多处理）支持，以便在多核系统中更好地管理硬件资源。

EDK2项目上游集成

• 持续进行的EDK2集成：OpenSBI与EDK2的集成正在逐步上游化，进一步扩展RISC-V的固件支持。

Oreboot

• 基于Rust的Coreboot：Oreboot项目是用Rust编写的Coreboot版本，目标是为RISC-V提供更加安全和可靠的固件解决方案。

LinuxBoot和其他引导加载程序

• LinuxBoot？：未来可能会为RISC-V提供LinuxBoot的支持，使启动流程更加简化和灵活。
• 其他引导加载程序？：随着RISC-V的生态系统不断发展，未来可能会出现更多的引导加载程序，进一步丰富启动选项。

通过这些即将到来的支持，RISC-V的启动流程将变得更加多样化和稳定，为开发者提供更灵活的工具链和启动选项，适应从嵌入式系统到高性能计算的广泛应用场景。

Ongoing Work

为了构建一个稳定且易于使用的RISC-V启动生态系统，当前有多个方面的工作正在进行中。这些工作涵盖了SBI规范的更新、OpenSBI的改进、以及Linux内核的持续开发。

SBI Specifications

• SBI v0.2 规范：新版SBI v0.2规范正在制定中，将带来更多改进和扩展。
• Hart状态管理扩展：在SBI v0.2中，将引入对Hart（硬件线程）状态管理的扩展，以便更好地控制和管理系统中的各个Hart。
• 替换旧版SBI扩展：SBI的遗留扩展将被更现代的功能替代，进一步优化性能和兼容性。

OpenSBI

• 通过CPU热插拔实现顺序CPU启动：改进OpenSBI以支持CPU热插拔，允许系统在运行时动态启动或关闭CPU。
• 支持其他M-mode引导加载程序：OpenSBI正在扩展以支持其他机器模式（M-mode）的引导加载程序，例如Coreboot和U-Boot SPL。
• 虚拟化支持：当SBI规范发生变化时，OpenSBI将增加对虚拟机管理程序（Hypervisor）的支持。
• 更多平台支持：OpenSBI计划扩展支持更多硬件平台，但这些扩展需要额外的硬件支持。

Linux Kernel

• SBI v0.2实现：SBI v0.2规范的实现正在进行中，补丁正在审查过程中。
• EFI stub的支持：EFI stub正在内核中开发，旨在提供完整的UEFI支持，这对企业级应用至关重要。
• 替换旧版SBI扩展：与OpenSBI一样，Linux内核也在逐步替换SBI的遗留扩展。
• 顺序启动：内核将支持顺序启动功能，确保系统能够按需有序地启动。
• CPU热插拔支持：内核正在开发对CPU热插拔的支持，以实现更灵活的系统资源管理。

Acknowledgements

在RISC-V启动生态系统的开发过程中，多个团队和个人做出了重要贡献。以下是对这些贡献者的感谢：

U-Boot

• Lukas Auler
• Bin Meng
• Anup Patel

Coreboot

• Ron Minnich
• Jonathan Neuschäfer
• Patrick Rudolph
• Philip Hug

EDK2

• Abner Chang

其他贡献者

• 感谢所有为RISC-V启动流程做出贡献的开发者和社区成员，他们的努力推动了整个生态系统的前进。

这些开发者和团队通过持续的贡献，使得RISC-V启动流程更加成熟，进一步推动了开源硬件平台的普及和发展。

Reference

• SBI
• EDK2

© 2019 Western Digital Corporation or its affiliates. All rights reserved. 12/19/19

More

The future of RISC-V Supervisor Binary Interface(SBI) - Atish Patra - Western Digital

OpenSBI Deep Dive - Anup Patel - Western Digital

An Introduction to RISC-V Boot flow: Overview, Blob vs Blobfree standards - Jagan Teki, Amarula Solutions - China RISC-V Forum - 2019, ShenZhen

【翻译】RISC-V SBI and the full boot process

原文作者： @popovicu

原文链接： RISC-V SBI and the full boot process

版权声明： 本文为 @popovicu 的原创作品。本文的翻译仅供学习参考，更多详细信息请访问原文链接。

RISC-V SBI 和完整的启动过程

发表于：2023年9月9日 | 晚上09:00

@popovicu94

在上一篇文章中，我们讨论了RISC-V上的裸机编程。在继续阅读本文之前，请先熟悉之前的内容，因为本文是对前述文章的直接延续。

这次我们将讨论 RISC-V 的 SBI（Supervisor Binary Interface，监督者二进制接口），并以 OpenSBI 作为示例。我们将探讨 SBI 如何帮助我们实现操作系统内核的基本功能，并以 riscv64 virt 机器为例结束本文。

RISC-V 和“BIOS”

在前文中，我们详细讨论了 RISC-V 启动过程的最初阶段。我们提到，首先运行的是 ZSBL（零阶段引导加载程序），它初始化一些寄存器并跳转到 ZSBL 硬编码的地址。在 QEMU 的 riscv64 virt 虚拟机中，这个硬编码的地址是 0x80000000。这就是用户提供的代码首次运行的地方，默认情况下，QEMU 会在这里加载 OpenSBI。

机器模式

到目前为止，我们避免讨论不同的机器模式，现在是引入它们的最佳时机。机器模式的概念在于，并不是每个软件都应该能够访问机器上的任意内存地址，甚至不是所有的指令都应该被 CPU 执行。传统的教科书示例中，通常有两种主要的权限划分：

1. 特权模式
2. 非特权模式

特权模式 是机器在启动时的模式。此时允许执行任何指令，且没有地址访问违规的概念。一旦操作系统接管系统控制并开始执行用户代码（即用户空间代码），模式就会开始切换。当用户代码在 CPU 核心上运行时，它是在 非特权模式 下运行，此时并不能访问所有资源。返回内核模式意味着切换回特权模式。

这是操作权限的一种非常教科书化的简化视角，但问题来了：为什么只有两种模式？

在系统中，通常有超过两种模式，形成多个访问模式的保护环。RISC-V 规范并没有明确规定一个核心必须实现哪些模式，除了 M（机器）模式，这是最具特权的模式。

通常，只有 M 模式的处理器是简单的嵌入式系统，而更安全的系统会支持 M 和 S 模式，直到可以运行类似 Unix 操作系统的完整系统（支持 M、S 和 U 模式）。

SBI

官方文档 提供了正式定义，我将在此对其进行简化解释，以帮助更直观地理解。

RISC-V 的 SBI 规范定义了 RISC-V 软件栈底层的软件层。这非常类似于 BIOS，后者通常是机器上运行的第一段软件。你可能看到过一些从零开始开发简单内核的指南，它们通常涉及与我们在RISC-V裸机编程指南中所做的类似操作，带有一点不同——它们往往依赖于一些预先存在的软件来完成某些 I/O 操作。与我们之前的指南相似之处在于，它们也仔细对齐了第一条指令的地址，以确保处理器的执行流程按预期进行，并且简单的内核能够在正确的时间接管。然而，我通常在这些简短的指南中观察到，目标通常是向VGA屏幕打印类似‘Hello world’的东西。最后这一点看起来相当复杂，事实上确实如此。

那么，如何轻松地向 VGA 打印内容呢？答案是 BIOS 在这里帮助我们完成最基本的 I/O 操作，例如向屏幕上打印字符，因此它被称为 Basic Input Output System（基本输入输出系统）！请注意裸机编程指南的开头部分：我们是在没有依赖于机器上任何现有软件的情况下与用户交互的（严格来说，这并不完全正确，我们仍然通过了零阶段引导加载程序，但我们并不依赖于它的任何结果，也无法真正控制它；它是系统中硬编码的）。如果我们要在 VGA 屏幕上打印内容，而不是通过 UART 发送字符，我们将需要做的不仅仅是向某个地址发送 ASCII 码。VGA 需要通过发送多个值来设置显示设备，配置不同的参数等。这是一个相当复杂的操作。

那么 BIOS 通常如何帮助处理这些任务？主要的概念是，无论最终在机器上安装了什么操作系统，它都需要一些基本功能，比如向 VGA 屏幕打印信息。因此，机器可以将这些标准操作预先集成到系统中，供任何操作系统使用。从概念上讲，我们可以将这些过程视为我们应用程序编写时所依赖的日常库。

此外，如果操作系统是针对这样的“库”编写的，它将自动变得更加可移植。“库”应该包含所有底层细节，例如“输出到 UART 意味着写入 0x10000000”（在 QEMU 的 riscv64 virt 虚拟机中），与“输出到 UART 意味着写入 0x12345678”相比，操作系统只需要调用“输出到 UART”的过程，而这个“库”将知道如何与硬件进行交互。

精妙的抽象

这些讨论归根结底是编程中从第一天就开始使用的一个非常简单的概念：我们在编程中应用了抽象层。想象一下，一个 Python 函数执行类似“将本地文件发送到电子邮件地址”的操作。从高层视角看，我们只是简单地调用一个函数 send_file_to_email(file, email)，然后底层的库会打开网络连接并开始传输字节。这可能是另一个 Python 库。在某个时刻，这个操作可能会下移到软件栈的底层，Python 库将依赖于用 C 语言编写的 Python 运行时，后者通过系统调用操作系统来执行核心操作（例如打开网络套接字）。操作系统的深处有一个网络驱动程序，它知道应该将字节发送到地址空间中的哪个地址，以便将字节通过网络传输出去。这里的主要概念是，我们已经建立了一种隐藏操作复杂性的方式，通过将它们委托给软件栈的底层来处理。我们并不是从原子部分构建更大的系统，而是从“分子”构建。

如果我们将复杂性委托给底层库，这可能只是一个函数调用。然而，一旦需要将复杂性委托给操作系统及以下层次，这就会通过一个二进制接口来实现。

二进制接口

自从计算机开始广泛使用以来，x86 架构一直是我们使用的台式机或笔记本电脑的主导架构。近年来，情况发生了很大变化，其他架构开始进入我们的视野，但让我们暂时集中于 x86。那么，是什么使为 Linux 构建的应用程序与 Windows 的应用程序不兼容呢？如果它是为 x86 编写的，并且 Linux 和 Windows 都运行在 x86 上，那么差异究竟在哪里？CPU 指令并没有因平台不同而改变，那么原因是什么呢？答案是应用程序和操作系统之间的接口。用户软件与操作系统之间的这个特定链接称为应用二进制接口（ABI）。ABI 只是一个定义，规定了如何从用户应用程序调用操作系统的服务。

因此，当我们说“这个软件是为平台 X 编写的”时，仅仅说 X 是 x86 或 RISC-V 还不够，我们必须明确说 x86/Linux 或 x86/Windows 或 RISC-V Linux 等。如果涉及动态链接，平台定义甚至可能更加复杂，但我们暂且不讨论这个问题。

让我们来看一个用汇编语言为 x86/Linux 编写的程序的简单例子，该程序只是将‘Hello’字符串打印到标准输出。

.global _start

.section .text

_start: mov $4, %eax ; 4 是 'write' 系统调用的代码
        mov $1, %ebx ; 我们正在写入文件 1，即 '标准输出'
        mov $message, %ecx ; 我们要打印的数据位于 message 符号定义的地址
        mov $5, %edx ; 我们要打印的数据长度是 5
        int $0x80 ; 调用系统调用，即请求内核将数据打印到标准输出

        mov $1, %eax ; 1 是 'exit' 系统调用的代码
        mov $0, %ebx ; 0 是进程的返回码
        int $0x80 ; 调用系统调用，即请求内核关闭该进程

.section .data
message: .ascii "Hello"

用以下命令汇编该程序：

as -o syscall.o syscall.s

链接：

ld -o syscall syscall.o

运行：

./syscall

你应该会看到输出“Hello”。如果你使用的是 Bash，并且想要检查进程的返回码，可以运行：

echo $?

你应该会看到 0。

提示：如果你没有 x86/Linux 机器，但想尝试上面的例子，可以通过一个模拟 x86 系统的 JavaScript 虚拟机来实现这里；这是一个非常酷的网站！

这样我们就得到了一个在 x86 机器上运行并在 Linux 内核下打印消息的程序。没有使用 C 标准库。最终生成的 ELF 二进制文件应该能够在 Linux 上运行，唯一的依赖条件是它运行在正确的平台上。

现在回到问题本身，是什么可能使这个二进制文件与 Windows 不兼容？不同的操作系统以不同的方式编码系统调用（例如，写入操作的代码在 Linux 是 4，而在 Windows 可能是 123，或者参数通过不同的 CPU 寄存器传递）。 现在你对如何直接与内核交互有了更好的理解，而不依赖标准库（尽管你几乎不会想这么做）。这意味着你已经揭示了软件执行诸如打开文件、分配内存、发送信号等操作的那一层。C 标准库可以看作是一个封装器，它隐藏了通过 int 指令调用软件中断与内核通信的复杂性，而是使其看起来像一个正常的 C 函数调用，但实际上它的底层机制就是这样。公平地说，库做的远不止这些，但对于本文的目的，可以简单地将其视为一个封装器。

现在在 RISC-V 的世界里，情况也是类似的：用户应用程序通过软件中断的 CPU 指令与内核交互，并通过 CPU 寄存器传递参数。而内核则通过 SBI 来调用它的服务，执行的方式完全相同！不同之处在于，这一层的逻辑调用被称为 SBI，而不是 ABI。可以把它理解为，这不是应用程序在工作，而是应用程序的监督者在工作。名称不同，概念却是完全一致的。

使用 OpenSBI 的实际示例

到此为止，我们已经明确了，SBI 和 ABI 类似，都是调用软件栈底层功能的一种方式。同时我们也明确了，SBI 处于 RISC-V 机器的软件栈的最底层，并在最具特权的 M 模式下运行。现在让我们进一步补充一些细节。

现在应该可以理解为什么 QEMU 开发者选择使用 -bios 标志来接受 SBI 软件镜像（因为其功能与 BIOS 基本相同）。需要提醒的是，-bios 标志应该指向一个 ELF 文件，该文件将从地址 0x80000000 开始布局 SBI 软件。

让我们在仅加载 OpenSBI 的情况下启动 QEMU 的虚拟机，看看会发生什么。我们不需要传递任何参数给 QEMU，因为默认情况下它会将 OpenSBI 加载到 0x80000000。

qemu-system-riscv64 -machine virt

这是输出（在串行端口上，不是 VGA）：

OpenSBI v0.8
   ____                    _____ ____ _____
  / __ \                  / ____|  _ \_   _|
 | |  | |_ __   ___ _ __ | (___ | |_) || |
 | |  | | '_ \ / _ \ '_ \ \___ \|  _ < | |
 | |__| | |_) |  __/ | | |____) | |_) || |_
  \____/| .__/ \___|_| |_|_____/|____/_____|
        | |
        |_|

Platform Name       : riscv-virtio,qemu
Platform Features   : timer,mfdeleg
Platform HART Count : 1
Boot HART ID        : 0
Boot HART ISA       : rv64imafdcsu
BOOT HART Features  : pmp,scounteren,mcounteren,time
BOOT HART PMP Count : 16
Firmware Base       : 0x80000000
Firmware Size       : 96 KB
Runtime SBI Version : 0.2

MIDELEG : 0x0000000000000222
MEDELEG : 0x000000000000b109
PMP0    : 0x0000000080000000-0x000000008001ffff (A)
PMP1    : 0x0000000000000000-0xffffffffffffffff (A,R,W,X)

虚拟机就这样一直运行下去，可能是因为默认情况下它被设置为这样运行，因为没有其他软件传递给 QEMU 来在 OpenSBI 之后接管控制。此时看来一切正常，OpenSBI 已经成功设置（其输出也确认它位于 0x80000000）。

接下来我们如何继续扩展软件栈呢？新的一层可以是操作系统内核，因此类似于我们之前构建的包含指令的 ELF 文件，它被放置在 0x80000000，我们将构建另一个 ELF 文件，供 QEMU 加载到内存中，但这次指令将加载到另一个地址，因为从 0x80000000 开始的部分已经被 OpenSBI 占用。

那么，我们应该将这个“虚拟内核”加载到哪个地址呢？

在 SBI 之后启动操作系统内核并调用 OpenSBI

当我们加载 BIOS/SBI/无论你想怎么称呼它时，这个地址基本上是“写死”在机器逻辑中的。最初的几条指令是零阶段引导加载程序（ZSBL），它的最后一条指令跳转到硬编码的地址 0x80000000。正如我们之前提到的，这是我们所使用的平台的不可更改的事实，它就是这样工作的。然而，这就是它目前所硬编码的全部内容：它只是硬编码了你必须从 0x80000000 开始，而我们现在已经在这里放置了 OpenSBI，那么 OpenSBI 接下来将带我们到哪里呢？

这时，ZSBL 的重要性再次出现了，现在它如何在执行跳转到 0x80000000 之前初始化这些寄存器真的很关键。ZSBL 实际上做了两件事：

1. 确保在 OpenSBI 初始化后运行的软件可以运行，这基本上是操作系统内核的引导加载程序，或者直接是内核本身（这就是你在 QEMU 指南中启动 Linux 时通常看到的，跳过引导加载程序，内存中直接加载内核）。
2. 跳转到 OpenSBI。

我们已经详细讨论了第二点，现在让我们深入探讨它如何完成第1点。

ZSBL 中究竟发生了什么？

我们之前提到 ZSBL 的执行从地址 0x1000 开始。让我们通过 QEMU 跟踪执行情况，看看发生了什么。为此，我们将在 QEMU 命令行中添加两个标志：-s 和 -S。这些标志确保 QEMU 暴露一个 gdb 调试端口，并且虚拟机在创建时立即暂停，等待我们通过 gdb 手动驱动它。

我们现在开始这个逆向工程的过程。我们首先启动 QEMU：

qemu-system-riscv64 -machine virt -s -S

在另一个终端中，我们连接到嵌入在 QEMU 中的 gdb 服务器，以便控制虚拟机的执行。我是在 x86 机器上执行的，所以我会使用 gdb-multiarch 来进行跨平台的 riscv 调试。在这个新的终端中，我运行以下命令：

gdb-multiarch

在连接到虚拟机之前，我想先设置几件事：

set architecture riscv:rv64

这行命令的作用显而易见。接下来，我希望每次执行一条指令时都能在终端中打印出实际的运行指令：

set disassemble-next-line on

现在是时候连接到 QEMU 的 gdb 服务器了（端口 1234 基本上是 QEMU 的默认设置，虽然可能可以通过 -s 标志进行某种方式的配置；不过我从未尝试过，也认为你不需要改变这个行为）。

target remote :1234

此时，gdb 正在等待我们，它停在了地址 0x1000，这是系统上电后执行的第一条指令的地址。我们将使用 si 多次单步执行指令，直到我们跳转到位于 0x80000000 的 SBI。

(gdb) target remote:1234
Remote debugging using :1234
warning: No executable has been specified and target does not support
determining executable automatically.  Try using the "file" command.
0x0000000000001000 in ?? ()
=> 0x0000000000001000: 97 02 00 00 auipc t0,0x0
(gdb) si
0x0000000000001004 in ?? ()
=> 0x0000000000001004: 13 86 82 02 addi a2,t0,40
(gdb) si
0x0000000000001008 in ?? ()
=> 0x0000000000001008: 73 25 40 f1 csrr a0,mhartid
(gdb) si
0x000000000000100c in ?? ()
=> 0x000000000000100c: 83 b5 02 02 ld a1,32(t0)
(gdb) si
0x0000000000001010 in ?? ()
=> 0x0000000000001010: 83 b2 82 01 ld t0,24(t0)
(gdb) si
0x0000000000001014 in ?? ()
=> 0x0000000000001014: 67 80 02 00 jr t0
(gdb) si
0x0000000080000000 in ?? ()
=> 0x0000000080000000: 33 04 05 00 add s0,a0,zero

在 ZSBL 中只有 6 条指令，之后控制权就交给了 OpenSBI，包含跳转指令。然而，这几条指令的意义是什么呢？

事实证明，这也是 SBI 规范的一部分，它是启动序列的一部分。然而，对于 OpenSBI，有三种不同的实现方式，在我们深入讨论 ZSBL 之后发生的事情之前，先来看看这些不同的实现方式。

OpenSBI 的三种实现方式

你可以通过三种不同的方式构建 OpenSBI：

1. FW_PAYLOAD（官方文档）
2. FW_JUMP（官方文档）
3. FW_DYNAMIC（官方文档）

FW_PAYLOAD

这个方式概念上最容易理解。构建这个版本的 OpenSBI 时，你会将 make 工具指向你的内核或“你希望在 OpenSBI 之后运行的任何软件”镜像，然后你将获得一个可以直接加载的单一二进制文件。在 QEMU 的虚拟机中，地址为 0x80000000。据我了解，可以调整你的软件在内存中与 OpenSBI blob 相关的位置，但为了简化起见，我们可以认为 OpenSBI 和你的软件被组合在一起成一个单一的 blob，一旦 OpenSBI 初始化完成，下一条指令就是你的软件（基本上 OpenSBI 之后直接过渡到你的软件）。

实现这个的方式是：

1. 确保在 make 过程中设置 FW_PAYLOAD=y，这将确保生成一个名为 fw_payload 的文件。
2. 在 make 过程中设置 FW_PAYLOAD_PATH，指向你希望在 OpenSBI 之后运行的软件。

根据上面链接的文档，如果你省略了第二个标志，OpenSBI 会与一个非常简单的无限循环软件一起拼接。这就解释了为什么当我们只启动 QEMU 而不加任何标志时，机器基本上只是原地打转——OpenSBI 很可能就是这样构建的（因为你不能继续执行随机的内存内容），它只是忙于原地等待。

这种方式的优点在于，现在你有了一个单一的、拼接的、整体的软件镜像，可以加载到你的机器中。你不需要处理多个独立的软件块，只需处理一个整体。如果你的软件构建过程比较简单，你甚至可能最终找到一种非常简单的方式来管理目标机器上的所有软件，同时还能享受 OpenSBI 为你提供的一些工作便利。

缺点是，现在你需要负责将所有东西拼接在一起，包括 OpenSBI。更糟的是，如果机器已经有了 OpenSBI，例如，烧录在某个 ROM 中，它已经有了启动 OpenSBI 的能力，重复加载 OpenSBI 可能会导致问题。

FW_JUMP

这种方式也相对简单：你基本上将 OpenSBI 之后的软件地址硬编码。类似于上述情况，也需要两步。

1. 确保在 make 过程中设置 FW_JUMP=y，这将生成一个名为 fw_jump 的文件。
2. 在 make 过程中设置 FW_JUMP_ADDR，指向 OpenSBI 完成后跳转的地址。

这与前一种情况非常相似，只是跳转地址是硬编码的。在这种情况下，你仍然需要负责构建 OpenSBI 镜像，但它易于重建，并且可以针对不同的机器指向不同的地址（例如，具有不同内存布局的机器）。

FW_DYNAMIC

这是最通用的方式，因此我们最后讨论这一种。在这种方式中，ZSBL 中寄存器设置的重要性开始显现出来。

在这种模式下，OpenSBI 之前的启动阶段负责向 OpenSBI 传递一些指针。在这个例子中，当然是 ZSBL。如果我们仔细观察，会看到它修改了寄存器 a2。

在这里，我鼓励读者阅读这篇文章中的 ZSBL 部分。整篇文章都很棒，只是我一开始觉得它有点难以理解，所以可以把本文看作是理解那篇文章的预备知识，值得花时间去阅读。

简单来说，ZSBL 设置 a2 寄存器的意义是什么？它指向一个 struct fw_dynamic_info 结构，这为动态 OpenSBI 提供了继续启动过程的方式！实际上，这个结构中的一项数据是 OpenSBI 之后运行的软件的地址。一个很好的问题是：在真实机器上，谁来填充这个结构？根据我们将看到的内容，显然 QEMU 会将该内容硬编码到内存中，这一逻辑并不是 ZSBL 的一部分，但我可以想象，在某些设备上 ZSBL 实际上会填充这个结构并传递给 OpenSBI。

来自西部数据的一名工程师的演讲的第17页（他可能是 OpenSBI 的核心贡献者）概述了这个 struct 的内容：

1. 魔术数
2. 版本号
3. 下一个地址
4. 下一个模式
5. 选项

所有这些都是无符号长整型（我猜是 64 位，8 字节？）。

探索 fw_dynamic_info 结构

到此为止，我们来一个快速的绕道，确保我们在讨论相同的版本。我们检查一下 OpenSBI 的版本，因为不同系统的 QEMU 可能带有不同版本的 OpenSBI。构建 OpenSBI 源码非常简单，让我们快速进行。首先，我们需要克隆 Git 仓库（本文写作时是 2023 年 9 月 10 日；如果你想要完全可重复的构建，可以使用这一天的提交版本）：

git clone https://github.com/riscv-software-src/opensbi.git
cd opensbi
make ARCH=riscv CROSS_COMPILE=riscv64-linux-gnu- PLATFORM=generic

构建速度应该非常快，且占用资源较少。我们感兴趣的输出文件是 build/platform/generic/firmware/fw_dynamic.bin。我们将通过 QEMU 的 -bios 标志来传递这个文件。从刚刚克隆的 opensbi 文件夹中启动 QEMU：

qemu-system-riscv64 -machine virt -s -S -bios build/platform/generic/firmware/fw_dynamic.bin

在 gdb 中执行几次 si 之后，我们回到之前的状态。让我们通过 gdb 查看 QEMU 的内存，以了解 ZSBL 结束时的情况。在 ZSBL 的最后一条指令处，我们查看寄存器转储（使用 i r 来查看）：

=> 0x0000000080000000: 33 04 05 00 add s0,a0,zero
(gdb) i r

结果显示 a2 指向 0x1028。正如我们所说的，让我们通过 gdb 检查该内存。我们让它读取从 0x1028 开始的 10 个连续的 8 字节值，并以十六进制格式显示。

(gdb) x/10xg 0x1028

g 标志用于以 8 字节的“巨大”块打印内存内容。

(gdb) x/10xg 0x1028
0x1028: 0x000000004942534f 0x0000000000000002
0x1038: 0x0000000000000000 0x0000000000000001
0x1048: 0x0000000000000000 0x0000000000000000
0x1058: 0x0000000000000000 0x0000000000000000
0x1068: 0x0000000000000000 0x0000000000000000

这大致符合Vysakh的文章中的描述。我们确实看到了文章中提到的魔术数，后面跟着的是 0x02 版本信息。接下来应该是下一个跳转的地址，但这里全是零……这有点奇怪，不过我们继续看。下一个值是 0x01，根据文章，它应该对应于执行的下一个模式，也就是 S 模式。这是正确的，我们从运行 SBI 的 M 模式切换到运行操作系统内核引导程序（或直接是内核）的 S 模式。为什么下一个跳转地址全是零呢？在这个时候，我决定让 QEMU 不再受 gdb 干扰而继续运行。我在 gdb 中运行以下命令：

continue

现在一切都停止了，但由于我正在运行更新版本的 OpenSBI，所以 UART 上输出了更新的内容：

OpenSBI v1.3-54-g901d3d7
   ____                    _____ ____ _____
  / __ \                  / ____|  _ \_   _|
 | |  | |_ __   ___ _ __ | (___ | |_) || |
 | |  | | '_ \ / _ \ '_ \ \___ \|  _ < | |
 | |__| | |_) |  __/ | | |____) | |_) || |_
  \____/| .__/ \___|_| |_|_____/|____/_____|
        | |
        |_|

Platform Name             : riscv-virtio,qemu
Platform Features         : medeleg
Platform HART Count       : 1
Platform IPI Device       : aclint-mswi
Platform Timer Device     : aclint-mtimer @ 10000000Hz
Platform Console Device   : uart8250
Platform HSM Device       : ---
Platform PMU Device       : ---
Platform Reboot Device    : syscon-reboot
Platform Shutdown Device  : syscon-poweroff
Platform Suspend Device   : ---
Platform CPPC Device      : ---
Firmware Base             : 0x80000000
Firmware Size             : 322 KB
Firmware RW Offset        : 0x40000
Firmware RW Size          : 66 KB
Firmware Heap Offset      : 0x48000
Firmware Heap Size        : 34 KB (total), 2 KB (reserved), 9 KB (used), 22 KB (free)
Firmware Scratch Size     : 4096 B (total), 768 B (used), 3328 B (free)
Runtime SBI Version       : 1.0

Domain0 Name              : root
Domain0 Boot HART         : 0
Domain0 HARTs             : 0*
Domain0 Region00          : 0x0000000002000000-0x000000000200ffff M: (I,R,W) S/U: ()
Domain0 Region01          : 0x0000000080040000-0x000000008005ffff M: (R,W) S/U: ()
Domain0 Region02          : 0x0000000080000000-0x000000008003ffff M: (R,X) S/U: ()
Domain0 Region03          : 0x0000000000000000-0xffffffffffffffff M: () S/U: (R,W,X)
Domain0 Next Address      : 0x0000000000000000
Domain0 Next Arg1         : 0x0000000087e00000
Domain0 Next Mode         : S-mode
Domain0 SysReset          : yes
Domain0 SysSuspend        : yes

Boot HART ID              : 0
Boot HART Domain          : root
Boot HART Priv Version    : v1.10
Boot HART Base ISA        : rv64imafdc
Boot HART ISA Extensions  : zicntr
Boot HART PMP Count       : 16
Boot HART PMP Granularity : 4
Boot HART PMP Address Bits: 54
Boot HART MHPM Info       : 0 (0x00000000)
Boot HART MIDELEG         : 0x0000000000000222
Boot HART MEDELEG         : 0x000000000000b109

这与我们之前看到的相符，接下来的地址全是零……这很奇怪，不可能是对的。我现在运行 QEMU 时没有让它暂停，而是让它直接运行，并异步连接 gdb。我就不详细说明了，但在这种“实时运行”中检查寄存器时，确实显示没有任何指令在 0x0000000000000000 区域执行。CPU 似乎在某个其他地址上循环。

这可能与我实际上没有向 QEMU 传递除了 OpenSBI 以外的其他软件有关，所以这可能导致了问题。QEMU 可能将该结构填充为全零，OpenSBI 识别到这是一个非法的边缘情况，因此它一直在 OpenSBI 中无休止地循环——这是我的推测。

我们如何传递一些除 OpenSBI 以外的软件呢？**与传递 OpenSBI 的方式相同，只是使用不同的标志！**这次我们使用 -kernel QEMU 标志。我们将如何构建这个软件？与之前的“伪 BIOS”构建方式相同，只是将其映射到不同的内存位置。让我们试着把它加载到 0x80200000。

构建一个“无限循环的伪内核”

我们的操作系统内核将无限循环。它将在 0x80200000 处包含一条跳转指令，永远保持在那里。以下是汇编源代码：

 .global _start
 .section .text.kernel

_start: j _start

链接脚本如下：

MEMORY {
  kernel_space (rwx) : ORIGIN = 0x80200000, LENGTH = 128
}

SECTIONS {
  .text : {
    infinite_loop.o(.text.kernel)
  } > kernel_space
}

有关如何使用这些文件构建可加载到 QEMU 的 ELF 映像的详细信息，请参阅原始的裸机编程文章。

一旦我们构建完成，我们会得到一个名为 infinite_loop 的 ELF 文件，可以作为我们的伪内核。现在我们运行 QEMU：

qemu-system-riscv64 -machine virt -s -S -bios build/platform/generic/firmware/fw_dynamic.bin -kernel ~/work/github_demo/risc-v-bare-metal-fake-kernel/infinite_loop

再次，我连接 gdb 并用 si 一步步执行到 ZSBL 结束。现在，当我查看臭名昭著的 0x1028 结构时，情况好多了，这证实了 QEMU 之前奇怪地填充了那个结构的理论。

=> 0x0000000080000000: 33 04 05 00 add s0,a0,zero
(gdb) x/10xg 0x1028
0x1028: 0x000000004942534f 0x0000000000000002
0x1038: 0x0000000080200000 0x0000000000000001
0x1048: 0x0000000000000000 0x0000000000000000
0x1058: 0x0000000000000000 0x0000000000000000
0x1068: 0x0000000000000000 0x0000000000000000

我们现在看到该结构中的新地址已经填充，正如预期的那样。这也反映在 UART 上的 OpenSBI 输出中。让我们通过 gdb 继续进入我们的伪内核，看看那里一切是否正常。

(gdb) break *0x080200000
Breakpoint 1 at 0x80200000
(gdb) continue
Continuing.

Breakpoint 1, 0x0000000080200000 in ?? ()
=> 0x0000000080200000: 6f 00 00 00 j 0x80200000

一切看起来都很正常。让我们总结一下：

1. ZSBL 是上电后运行的第一段代码。它初始化了一些寄存器，关键的寄存器是 a2，它指向一个 fw_dynamic_info 结构，该结构包含 OpenSBI 动态模式操作的关键信息。在 QEMU 的情况下，这个结构在上电时被虚拟化引擎神奇地填充，但在现实中，这很可能是 ZSBL 的工作。不管怎样，OpenSBI 现在知道完成后要做什么。
2. OpenSBI 提供了一个基于中断的接口，供上层软件（大概是操作系统内核引导程序或内核本身）调用。这个接口称为 SBI，它在概念上与操作系统之上的应用程序软件的 ABI 相同。
3. 我们将内核映像作为另一个 ELF 文件传递给 QEMU，加载到内存的另一个区域。QEMU 填充该结构，使得 OpenSBI 能够将控制权传递到那里，并且在切换到那里之前，它会进入 S 模式。

有意略过的细节

ZSBL 还修改了 a0 和 a1 寄存器。

a0 与 RISC-V 的 hart 有关，但我们不深入探讨这些细节，因为它们对本文的其余部分没有太大相关性。此外，这个引导过程中的这一步似乎并不重要，参见Github评论。

a1 是一个有趣的指针，它指向内存中的设备树数据结构。对于本文的其余部分，这个数据结构并不相关，因此我们可以忽略它。然而，对于像 Linux 这样的真实内核，设备树非常有用。Linux 能够从内存中扫描设备树，并了解它运行的机器的结构，而不是针对每种硬件组合编写大量的 if/else 分支。你可以从维基百科文章中了解它在 Linux 中的使用情况。不过，正如所提到的，我们不会在本文中讨论设备树的细节。

Hello World 伪内核

现在我们已经掌握了足够的知识，可以编写一个伪操作系统内核，它只是在 UART 设备上打印“Hello world”。这个功能与我们在前一篇文章中看到的裸机程序没有太大区别，但我们到达目标的方式有显著不同。这次，我们将通过 SBI 调用来打印到 UART，而不是直接与 UART 设备交互（我们将这项工作委托给一个更底层的特权软件层）。即使在像“Hello world”这样简单的例子中，这也可能带来重大影响：我们将与 UART 硬件交互的责任委托给 SBI 层，从而实现跨不同符合 SBI 接口的机器的可移植性。

如何调用 RISC-V 的 SBI 层？概念上，这与在 x86 Linux 上调用标准输出打印非常相似——我们需要填充一些寄存器并触发软件中断/陷阱，将控制传递到软件栈的底层 OpenSBI。OpenSBI 在 SBI 层提供了许多服务，其中许多服务对于开发可移植的操作系统内核非常有用，例如与定时器的交互（这与时间切片和使多个线程共享同一 CPU 核心相关）。有关 SBI 层暴露的全部功能列表，请查看这里。

在本指南中，我们将专注于调试控制台功能，即通过 SBI 向 UART 写入内容。让我们开始编写代码吧！

首先，我们需要知道如何通过寄存器编码我们希望 OpenSBI 执行的功能。这在这里有详细记录。简而言之，SBI 功能被分组到“扩展”中。寄存器 a7 包含扩展 ID (EID)，而 a6 编码该扩展中的功能 ID (FID)。然后通过 a0、a1、a2 等寄存器传递参数。

要打印到控制台，我们需要的 EID 是 0x4442434E（一个相当有趣的值），而 FID 则是 0x00。

这次，和之前裸机编程指南中的逐字打印不同，我们将一次性调用打印功能。毕竟，我们应该从 SBI 层提供的高级功能中受益。因此，我们的二进制文件应该将输出字符串存储在内存中的某个地方，理想情况下，我们希望通过调用 SBI 从该地址开始打印。我们将这样做：

        .global _start
        .section .text.kernel

_start: li a7, 0x4442434E
        li a6, 0x00
        li a0, 12
        lla a1, debug_string
        li a2, 0
        ecall

loop:   j loop

        .section .rodata
debug_string:
        .string "Hello world\n"

这里有几个需要注意的地方：

1. 我们在这里使用了 PC 相对寻址来处理输出字符串。需要提醒的是，内核存储在一个非常大的无符号整数表示的地址上。这个值太大，无法用任何 RISC-V 32 位指令字编码。这不是问题，我们只需使用一小段 AUIPC 和 ADDI 指令即可到达那里（有关更多信息，请查看这篇文章）。如果你不理解这一点，请务必复习不同的内存寻址模式及其差异：这是任何裸机编程的关键。由于这是一个常见的模式，RISC-V 汇编器提供了一个伪指令 LLA，我们在这里使用了它。
2. SBI 需要将要打印的字符串指针分为两部分传递。可以看到其中一部分是 0。我不太确定为什么需要这样，但这是 API 设计的要求。

SBI 调用涉及的寄存器

1. a7 标识 SBI 扩展。
2. a6 标识扩展中的功能（在本例中是调试控制台扩展）。
3. a0 包含需要发送到调试控制台输出的字符串长度。
4. a1 和 a2 结合在一起，形成指向需要打印的字符串地址的 64 位指针。

SBI 调用通过 ecall 指令触发，它会激活 CPU 陷阱。此时，OpenSBI 接管并通过 UART 输出数据，方式与我们在最初的裸机编程指南中所做的完全相同。如果你想知道为什么简单的 ecall 调用会将控制权交给 OpenSBI，这是因为 OpenSBI 设置了陷阱处理机制，当我们的内核进入陷阱时，程序计数器会跳转到 OpenSBI 的软件部分。这些细节超出了本文的范围，但我们可能会在其他文章中详细讨论。

现在，只需查看 QEMU 的串行端口，确认“Hello world”已正确打印：

qemu-system-riscv64 -machine virt -s -S -bios build/platform/generic/firmware/fw_dynamic.bin -kernel ~/work/github_demo/risc-v-bare-metal-fake-kernel/hello_world_kernel

输出应该如下所示：

OpenSBI v1.3-54-g901d3d7
   ____                    _____ ____ _____
  / __ \                  / ____|  _ \_   _|
 | |  | |_ __   ___ _ __ | (___ | |_) || |
 | |  | | '_ \ / _ \ '_ \ \___ \|  _ < | |
 | |__| | |_) |  __/ | | |____) | |_) || |_
  \____/| .__/ \___|_| |_|_____/|____/_____|
        | |
        |_|

Platform Name             : riscv-virtio,qemu
Hello world

作为练习，我建议通过 gdb 探索基础扩展（0x10），以调查你构建的 QEMU 机器和 OpenSBI 能提供哪些功能。

结论

最终，我们得到了一个完全可移植的伪内核，它能够通过 UART 打印“Hello world”！虽然看起来不特别，但其背后的概念非常强大。你可以在支持调试控制台扩展的不同 RISC-V 64 位机器上直接使用相同的内核映像，无需重新构建。

事实上，我在这里玩了个小技巧 :) 让我建议你从源代码构建 OpenSBI 的原因之一是，某些 Linux 发行版包管理器提供的 QEMU 版本不支持调试控制台扩展（它们的版本较旧）。这正是我在 Debian 的 QEMU 中默认使用的 OpenSBI 遇到的情况。

最后，提醒大家我们主要关注的是带有 RISC-V 核心的 QEMU virt 机器，本文的所有细节都与此相关。不过，我希望读者已经了解了足够的启动顺序和裸机编程概念，以便将这些知识轻松应用到现实中的特定场景。

在接下来的文章中，我们将讨论如何进一步引导完整的 Linux 内核，并逐步扩展，直到我们实现一个能够处理键盘、鼠标、屏幕和以太网网络的 Linux 部署。

希望你喜欢这篇长篇文章！

代码指引

如果你不想复制粘贴代码，它可以在这个 GitHub 仓库中找到。

【翻译】Bare metal programming with RISC-V guide

原文作者： @popovicu

原文链接： Bare metal programming with RISC-V guide

版权声明： 本文为 @popovicu 的原创作品。本文的翻译仅供学习参考，更多详细信息请访问原文链接。

RISC-V 裸机编程指南

发表于：2023年9月9日 | 上午12:05

@popovicu94

今天我们将探讨如何为 RISC-V 机器编写一个裸机程序。为了确保可重复性，我们将目标设定为 QEMU 的 riscv64 virt 虚拟机。

我们将简要介绍 RISC-V 机器启动的初始阶段，以及如何插入你自己的定制软件来进行裸机编程！

在本文的结尾，我们将为我们的 RISC-V 机器编写一个裸机程序，并向用户发送字符串“hello”，而不依赖于运行机器上的任何支持软件（操作系统内核、库等）。

机器启动和初始软件运行

一般概念

如果你熟悉计算机如何启动，可以跳过这一部分。

当一台真实的机器启动时，硬件首先运行健康检查，然后将要运行的第一批指令加载到内存中。一旦指令加载完成，处理器核心初始化其寄存器，程序计数器指向第一条指令。从那时起，软件便可以运行。

在像小型微控制器这样的简单系统中，所有的软件都包含在一个单一的二进制指令块中。处理器接下来将只执行这些指令。在像笔记本电脑或手机这样的更复杂的系统中，启动有更多阶段。

在这些复杂系统中，传统上，第一批指令是 BIOS，它的任务是将引导加载程序加载到内存中并将控制权移交给它。引导加载程序通常很小，便于加载到运行内存中，处理器可以轻松开始执行它的代码。然后它将操作系统内核加载到内存中（实现引导加载程序本身就是一门学问）。

每台机器以自己的方式加载初始软件。例如，BIOS 可以存储在一个独立的存储芯片上，通电后，存储的内容将被加载到内存中的固定地址，然后处理器从该地址开始执行。

QEMU 启动

即使 riscv64 virt 机器是虚拟的，它仍然有自己的启动顺序。它会经历多个阶段，目前我们不会探索所有细节。请关注后续文章中的更多详细介绍。

理解这个虚拟机的关键在于，显然它没有连接读取软件的芯片（它是虚拟的），所以 QEMU 通过某种方式模拟这一过程。你可能在之前的 QEMU 示例中见过 -bios 标志，现在你应该能对它有一个强烈的直觉。如果你猜测这是传递你的虚拟 RISC-V 核心在启动时执行的第一批指令，你是几乎正确的*。

零阶段引导加载程序 (ZSBL)

一旦你启动了这个虚拟机，QEMU 就会在 0x1000 地址填充一些指令，并将程序计数器设置为该地址。这相当于一台真实的机器在板上有一些硬编码的 ROM 固件（存放在某个芯片中），并在启动时将其内容转储到 RAM 中。你无法控制这些指令，它们不是你软件镜像的一部分，通常来说，我认为你没有理由想要覆盖这些指令，而且它们实际上对于更复杂的设置非常有用（我保证我们会在后续文章中讨论它们）。对于好奇的人来说，这几条指令就是零阶段引导加载程序（ZSBL）。ZSBL 设置了一些寄存器，具体原因我们将在未来探索（现在，你可以基本忽略这些寄存器的设置），并跳转到 0x80000000 地址，这才是真正的“战斗”开始的地方！

QEMU 的 -bios 标志

0x80000000 是 QEMU 开始运行用户提供的第一条指令的地址，这些指令在虚拟机启动时立即加载。如果你不传递任何东西，QEMU 将使用默认设置，并加载一个名为 OpenSBI 的软件。下一篇文章将详细介绍 RISC-V 中 SBI 的概念，以及 OpenSBI 究竟是什么。需要注意的是，RISC-V 中的 SBI 并不是真正的 BIOS，而是非常类似的东西。我的个人猜测是，QEMU 作者简单地复用了在其他架构（如 x86）上代表 BIOS 的标志。不过需要记住的是，SBI 在功能上与 BIOS 非常相似，更重要的是，它是可以定制的。

-bios 标志接受一个 ELF 二进制文件，包含指令和其他数据，按段组织。ELF 是 Linux 的标准二进制格式，虽然 ELF 文件格式的详细内容超出了本文的讨论范围，但我们可以简化理解为它是一个键值对映射，其中键是段的起始地址，值是需要加载到该地址的字节序列。因此，传递给 -bios 标志的 ELF 文件会填充从 0x80000000 开始的内存（这正是 QEMU 默认的 OpenSBI 镜像所做的事情）。

关于 -kernel 标志的说明

如果你之前用 QEMU 启动过操作系统（例如 Linux），你可能用过 -kernel 标志。它的作用基本与 -bios 标志相同：你可以传递一个 ELF 映像，覆盖其他内存区域，从概念上讲，它只是将字节转储到内存中。我们今天不会使用这个标志，但会在后续文章中详细介绍它的用法。

ELF 文件如何在启动过程中使用？

虽然概念上 ELF 文件只是一种填充内存的方法，但它们绝对不简单，你无法在一个下午编写一个简单的解析器。细心的读者可能会想：机器如何知道从 ELF 文件中解析出映射到某个地址（如 0x12345678）的内容并将其加载到内存中？这是个很好的问题——在我们的案例中，我们使用的是虚拟机，基本上是在模拟一台拥有智能数字电路或极其复杂的初始软件引导程序的机器，而这些内容在机器上电时已经准备好存储在内存中。当然，这不是在真实机器中发生的事情。真实机器上电时加载的软件是存储在机器存储器中的平坦二进制块，上电时它会直接被转储到内存中，实际上并没有任何解析过程。但由于我们在这里处理的是虚拟机器，几乎没有限制，我们无需受到制造硬件复杂性的约束。

为 RISC-V 编写自定义 “BIOS”

我们已经确定 0x80000000 是机器执行的第一条用户提供指令的位置。我只是将其作为一个事实给出，如果你想了解更多背景，可以从这里开始。基本上，我们看到的是，DRAM 在地址空间中映射为从 0x80000000 开始（如果你不理解这是什么意思，不用担心，本文接下来的内容对这个概念的依赖不大）。

让我们开始构建一个 ELF 文件，它将在地址 0x80000000 处布置一些处理器指令，以向用户显示消息“hello”！

通过 UART 与用户交互

曾经做过嵌入式系统编程的人肯定熟悉 UART 的概念。UART 是一种非常简单的设备，用于最基本的输入/输出形式：它有一根输入线（接收，称为 RX）和一根输出线（发送，称为 TX），每次传输一位。如果你要连接两台设备通过 UART 通信，一台设备的 TX 连接到另一台设备的 RX，反之亦然。如果你阅读本文时从未接触过 UART，我强烈建议你至少购买最便宜的 Arduino，并通过 USB 转 UART 电缆与计算机通信。这个概念与我们在这里做的完全相同，但你将真正动手操作，理解会更加深刻，因为这里的场景是完全虚拟化的。

QEMU 虚拟化了虚拟机上的 UART 设备，我们的软件可以访问它。当你打开 QEMU 的串行端口（UART）部分时，基本上当你按下键盘上的按钮时，按键的代码会从主机的 TX 发送到虚拟机的 RX，而当虚拟机在其 TX 上输出某些内容时，它会在终端中图形化显示给你（因此你不必解码来自模拟板的电信号 :）），例如，如果虚拟机发送 8 位代表 65 的数据，你的 QEMU 将显示字符 a，因为这是它的 ASCII 代码。

我们知道 QEMU 将 UART 映射到地址 0x10000000（可以在 QEMU 的源代码中查看），这里虚拟化的设备是 NS16550A。具体细节不重要：对于本文的目的来说，这意味着如果你从软件中向该地址发送一个 8 位值，它将通过虚拟化的 UART 设备的 TX 线路发送出去。实际上，这意味着如果你打开 QEMU 的串行端口，你写入 0x10000000 的字符将显示在你的控制台中。

将代码整合在一起

了解了所有这些知识后，我们现在可以编写代码。我们即将构建的 ELF 文件会在地址 0x80000000 上布局一些指令，这些指令依次将字符 ‘h’、‘e’、‘l’、‘l’ 和 ‘o’ 发送到地址 0x10000000。最后，代码会进入一个无限循环（这样 QEMU 不会由于某些奇怪的原因崩溃，并且我们可以检查输出）。

 .global _start
 .section .text.bios

_start: addi a0, x0, 0x68
 li a1, 0x10000000
 sb a0, (a1) # 'h'

 addi a0, x0, 0x65
 sb a0, (a1) # 'e'

 addi a0, x0, 0x6C
 sb a0, (a1) # 'l'

 addi a0, x0, 0x6C
 sb a0, (a1) # 'l'

 addi a0, x0, 0x6F
 sb a0, (a1) # 'o'

loop: j loop

将此文件保存为 hello.s。让我们将这个文件汇编为机器码。在我的情况下（可能也是你的情况），我使用了跨平台的工具链，这意味着我在与目标平台不同的平台上进行开发。具体来说，我在 x86 机器上开发此软件，并为 riscv64 机器构建。

要汇编此文件，我运行以下命令：

riscv64-linux-gnu-as -march=rv64i -mabi=lp64 -o hello.o -c hello.s

具体命令可能会根据你使用的 riscv64 汇编器有所不同，这是我通过 Debian 系统的包管理器获得的工具。我建议你通过互联网获取构建 riscv64 软件的正确工具链，通常只需获取正确的软件包。

现在，代码只是被汇编了，这意味着我们已经将软件指令转换为机器码格式，但这个二进制文件还不能作为我们的伪 BIOS 使用。我们需要使用 链接器 并通过 链接脚本 来确保生成的指令按预期布局在 0x80000000 地址。让我们编写链接脚本。

MEMORY {
  dram_space (rwx) : ORIGIN = 0x80000000, LENGTH = 128
}

SECTIONS {
  .text : {
    hello.o(.text.bios)
  } > dram_space
}

我们不会深入解释这些内容的含义，但简而言之，现在我们有一种方法可以将这些指令准确地放置在我们想要的位置。让我们用 objdump 验证一下。

riscv64-linux-gnu-objdump -D hello

输出应该类似如下：

Disassembly of section .text:

0000000080000000 <.text>:
    80000000: 06800513           li a0,104
    80000004: 100005b7           lui a1,0x10000
    80000008: 00a58023           sb a0,0(a1) # 0x10000000
    8000000c: 06500513           li a0,101
    80000010: 00a58023           sb a0,0(a1)
    80000014: 06c00513           li a0,108
    80000018: 00a58023           sb a0,0(a1)
    8000001c: 06c00513           li a0,108
    80000020: 00a58023           sb a0,0(a1)
    80000024: 06f00513           li a0,111
    80000028: 00a58023           sb a0,0(a1)
    8000002c: 0000006f           j 0x8000002c

在 QEMU 上运行“伪 BIOS”

现在可以通过运行以下命令启动 QEMU：

qemu-system-riscv64 -machine virt -bios hello

要查看 UART 上发生的情况，请点击顶部菜单中的 View 按钮并切换到串行端口视图。输出应该如下图所示：

我只想运行代码

访问本文的 GitHub 仓库，运行 make 命令，它将执行我们上述的所有步骤。然后你可以启动 QEMU。

RISC-V Privileged Architecture

本讲座是由Allen Baum在第八届RISC-V研讨会上，于2018年5月7日在西班牙巴塞罗那进行的，讲述了RISC-V特权架构的内容。该架构是RISC-V处理器设计中的关键部分，决定了系统不同操作模式下的安全性、隔离性和性能。此幻灯片的内容重点阐述了特权架构的基本组成部分及其在处理器功能中的作用。

原始内容来源：

幻灯片标题：RISC-V Privileged Architecture

原作者：Allen Baum Esperanto Technologies.

出处：8 th RISC-V Workshop Barcelona, Spain

原始发布日期：2018年5月7日

版权声明：该幻灯片及其内容的版权归 Allen Baum 所有。翻译与讲解仅供学习和参考，更多详细信息请参见原文链接。

这是2018年发布的RISC-V特权架构资料，其中的大部分内容仍然与当前的RISC-V架构相关和有效，特别是在架构的基础概念、特权模式、控制状态寄存器（CSRs）和特权指令方面。然而，随着RISC-V的持续发展和标准的更新，部分技术细节可能已经有所改进或扩展。

如果你希望深入了解RISC-V在某些特定领域的最新进展，建议参考最新的RISC-V规范，或者查阅RISC-V基金会的最新文档和技术报告。

目录

为什么需要特权架构？

在处理器架构中，引入特权级别的目的是为了提供更高的系统安全性和资源控制。特权架构确保操作系统和用户程序运行在不同的权限级别，防止普通应用程序访问或修改关键的系统资源。例如，操作系统需要完全访问硬件资源和内存管理功能，而用户程序则只应在受限的环境下运行，以避免误操作或恶意行为影响整个系统的稳定性。特权架构通过分离不同的权限模式，帮助实现系统的可靠性和安全性。

配置文件（Profiles）

RISC-V特权架构根据不同的应用场景设置了不同的配置文件（Profiles），以适应多样化的需求。这些配置文件的存在使得RISC-V架构能够在嵌入式系统、服务器、移动设备等不同领域中灵活应用。每个Profile可以包括不同的功能和特权级别，从而满足特定应用的需求。

权限级别和模式（Privileges and Modes）

RISC-V特权架构划分了几种不同的权限模式，这些模式对应处理器在不同上下文中的操作需求。常见的模式包括：

• 机器模式（M模式）：这是RISC-V系统中最高的权限模式，通常由系统固件或低级别管理程序使用，直接控制硬件。
• 监督模式（S模式）：用于操作系统内核，允许访问部分硬件资源，但受到比机器模式更多的限制。
• 用户模式（U模式）：最低权限的模式，用户应用程序在此模式下运行，无法直接访问硬件或特权指令。

不同的模式通过硬件层级来隔离，确保每个级别的程序只能访问其权限范围内的资源。

特权功能（Privileged Features）

控制和状态寄存器（CSRs）

控制和状态寄存器是RISC-V特权架构中的重要部分，用于管理处理器的操作模式和状态。在特权模式下，CSRs控制包括中断、内存管理、性能计数等各种功能。不同的模式可以访问不同的CSRs，确保系统安全性。例如，用户模式无法修改系统级别的CSRs。

特权指令

RISC-V定义了一系列特权指令，这些指令只能在特定模式下运行，主要用于管理硬件资源和处理系统级别的操作，如中断处理和内存保护。

内存寻址（Memory Addressing）

内存寻址机制包括地址翻译和保护功能。RISC-V采用了一种分页机制来实现虚拟内存管理，允许操作系统将物理内存抽象为更灵活的虚拟地址空间。内存保护则确保不同模式下的程序只能访问特定范围的内存，避免越权访问。

地址翻译（Translation）

地址翻译通过页表将虚拟地址映射到物理地址，支持多级页表结构以提高寻址灵活性和效率。这一机制使得RISC-V处理器能够支持大规模内存应用和多任务处理。

内存保护（Protection）

内存保护的核心是防止低权限程序访问或修改高权限内存区域。通过在页表中设置访问权限位，RISC-V能够有效地隔离不同权限模式下的内存访问。

异常处理（Trap Handling）

异常处理机制用于处理运行过程中出现的各种异常情况，包括硬件中断和软件异常。RISC-V特权架构对这些异常的处理进行了细致的定义，确保系统能够在发生异常时迅速恢复或进行适当的操作。

异常（Exceptions）

当发生例如非法指令、访问未授权内存等异常情况时，处理器会捕获这些异常并转入相应的处理程序。这些异常处理程序通常运行在高权限模式下，以确保能够正确恢复系统。

中断（Interrupts）

RISC-V支持硬件和软件中断处理。硬件中断通常由外部设备引发，而软件中断则由处理器内部指令触发。中断处理需要快速响应并恢复正常执行，这也是操作系统设计中的一个关键部分。

计数器（Counters）

RISC-V架构中的计数器用于记录处理器的时间和性能信息。通过这些计数器，操作系统可以监控系统的运行状态，执行诸如时间片轮转、性能调优等任务。

时间（Time）

时间计数器记录系统运行的时间戳，用于系统时钟、定时器和其他时间相关功能。

性能（Performance）

性能计数器用于测量处理器的性能参数，如指令执行数、缓存命中率等。这些数据有助于优化系统性能，并为开发者提供性能调试信息。

Why a Privileged Architecture?

RISC-V特权架构的设计背后有着明确的目的，主要是为了更好地管理共享资源、保护系统的核心功能，并隔离具体实现的细节。共享资源的管理和保护对于现代计算系统至关重要，尤其是在多核、多任务环境中，特权架构的存在能够确保不同任务之间的安全隔离和资源分配。同时，它还提供了软件与硬件层的通信机制，尤其是在虚拟化支持方面，RISC-V架构通过引入一系列执行环境（Execution Environments）实现不同层次的任务隔离和资源共享。

管理共享资源

共享资源包括内存、I/O设备以及处理器核心。在多任务操作系统中，不同任务会争夺这些资源，而没有特权架构的管理会导致系统冲突和崩溃。通过特权架构，系统能够高效地分配这些资源，并在不同任务之间进行适当的隔离与协调。

关键资源管理包括

• 内存：虚拟内存映射使得各个任务能够使用独立的地址空间，从而避免直接访问物理内存。
• I/O设备：通过虚拟内存映射，系统能够保护设备接口，防止低权限任务直接访问关键I/O资源。
• 处理器核心：特权架构可以管理处理器核心的分配，确保高权限任务优先运行。

保护共享资源

资源保护是特权架构的另一个重要目的。通过使用虚拟内存映射以及访问权限控制，RISC-V能够有效防止任务间的越权访问和资源冲突。

具体的保护手段包括

• 内存保护：通过虚拟内存，系统可以为每个任务分配独立的内存空间，防止任务间的非法访问。
• I/O保护：与内存一样，I/O访问也被映射到虚拟地址空间，通过特权级别控制，防止低权限模式直接操作硬件设备。
• 访问权限控制：权限位可以设置在内存映射中，以确保只有特定权限模式能够访问相应的资源。

隔离实现细节

在多任务、多用户环境中，隔离不同实现的细节非常重要。特权架构通过捕获未实现的操作并通过软件仿真进行处理，从而能够兼容不同的实现。此外，处理异步事件（如I/O事件、计时器事件、软件中断）也是特权架构的重要任务，确保外部事件能够被及时响应并处理。

具体措施包括

• 未实现操作的捕获和仿真：当任务执行一个硬件不支持的操作时，特权架构能够捕获该操作并交由软件进行仿真。
• 外部异步事件处理：如I/O设备事件、计时器中断、线程间的中断等，特权架构能够管理这些事件的优先级和处理流程。
• 两级地址转换：为了支持虚拟化，RISC-V引入了两级地址转换机制，特别是在虚拟机管理程序（Hypervisor）模式下，这一机制至关重要。

RISC-V Privileged Architecture Layers

RISC-V特权架构分为多个层次，每个层次负责不同的执行环境，并通过特定的接口进行通信。这些层次清晰地划分了应用程序、操作系统、虚拟机管理程序之间的权限和功能，确保系统的可扩展性和安全性。

主要层次

1. 应用层（Application）：

   • 应用执行环境（AEE）：为应用程序提供一个运行环境，通过**应用二进制接口（ABI）**与底层系统进行交互。

2. 操作系统层（Operating System）：

   • 监督执行环境（SEE）：操作系统运行在监督模式下，管理系统资源，并通过**系统二进制接口（SBI）**与硬件进行通信。

3. 虚拟机管理程序层（Hypervisor）：

   • 虚拟机管理程序执行环境（HEE）：支持虚拟化，虚拟机管理程序能够通过虚拟机管理程序二进制接口（HBI）与操作系统层进行交互，管理虚拟机的执行。

层次间的通信

每一层都有其特定的二进制接口，通过这些接口，应用程序、操作系统和虚拟机管理程序能够顺利地进行通信和资源管理。例如，应用程序通过ABI接口调用操作系统的服务，而操作系统通过SBI接口管理底层硬件资源。

通信接口包括

• ABI（Application Binary Interface）：应用程序通过ABI与操作系统交互。
• SBI（System Binary Interface）：操作系统通过SBI直接与硬件进行通信。
• HBI（Hypervisor Binary Interface）：虚拟机管理程序通过HBI接口管理虚拟化环境中的资源和操作系统。

特权层次间的指令通信：ECALL指令

RISC-V引入了ECALL指令来实现不同权限层次之间的通信。当应用程序需要访问高权限功能时，它可以发出ECALL指令，这一指令会触发进入监督模式或虚拟机管理模式进行相应处理。这样，系统能够在保护低权限程序不直接访问高权限功能的同时，提供必要的功能调用接口。

支持虚拟化

RISC-V的所有ISA层次都设计为支持虚拟化。通过虚拟化，操作系统和应用程序可以在不同的虚拟机中运行，彼此隔离而不会影响底层硬件的安全性和资源分配。虚拟化的实现依赖于特权架构中的多级地址翻译机制和特定的二进制接口。

Profiles

在RISC-V特权架构中，"Profiles"定义了处理器可以支持的不同配置和特性集，以适应从简单嵌入式系统到复杂的云计算环境不等的应用需求。每个Profile描述了特定的操作模式、信任级别、内存保护方式以及其他特性，这些都是为了优化特定的使用场景而设计的。

主要的RISC-V Profiles

1. Embedded without Protection：
   • 模式（Modes）：M（机器模式）
   • 信任（Trust）：所有代码均可信
   • 内存保护（Mem Protect）：无
   • 其他特性（Other）：成本低廉，拥有16B的架构状态、计时器和计数器

这个Profile适用于需要极低成本和资源使用的简单嵌入式设备，如简单的传感器或控制器。不支持内存保护，意味着所有代码都运行在机器模式下，具有完全的硬件访问权限。

2. Embedded with Protection：
   • 模式（Modes）：M+U（机器模式和用户模式）
   • 信任（Trust）：应用不可信
   • 内存保护（Mem Protect）：物理内存保护
   • 其他特性（Other）：可选的N扩展，用于用户中断处理

这个Profile适用于需要隔离应用程序的更复杂嵌入式系统。通过引入用户模式，提高了系统的安全性，避免了不可信应用直接访问关键硬件资源。

3. Unix-like OS Capable：
   • 模式（Modes）：M+S+U（机器模式、监督模式和用户模式）
   • 信任（Trust）：操作系统可信
   • 内存保护（Mem Protect）：虚拟内存和读写执行（RWX）保护
   • 其他特性（Other）：支持不同的虚拟地址大小（32位、39位、48位）

此Profile旨在支持类Unix的操作系统，提供完整的内存虚拟化支持和多用户环境。操作系统运行在监督模式下，管理用户模式下运行的应用程序。

4. Cloud OS Capable：
   • 模式（Modes）：M+V（机器模式和可选的Hypervisor模式）
   • 信任（Trust）：Hypervisor可信
   • 内存保护（Mem Protect）：两级虚拟内存和RWX保护
   • 其他特性（Other）：支持Unix+，支持多操作系统，新的后台CSR

专为云计算环境设计，支持虚拟化技术，允许在同一硬件上运行多个虚拟机和操作系统。Hypervisor模式提供硬件级别的隔离和资源管理，优化了多租户环境的安全性和性能。

Profiles的应用

通过这些不同的Profiles，RISC-V能够为广泛的市场和应用提供灵活的解决方案。无论是低成本的嵌入式设备还是高性能的云服务器，RISC-V架构都能通过选择合适的Profile来最大化硬件的效能和适应性。这种灵活性是RISC-V在现代计算领域中逐渐成为一个重要选项的关键因素。

Privileges and Modes

RISC-V特权架构通过设置多种权限级别和操作模式来确保系统的安全性和功能完整性。这些权限模式为不同类型的任务分配了不同的权限，以确保高权限任务能够安全地管理硬件资源，而低权限任务则受到适当的限制。这种设计不仅提升了系统的安全性，还支持虚拟化、多任务处理等复杂应用。

RISC-V权限模式（Privilege Modes）

RISC-V定义了一个分层的权限模式结构，分为用户模式、监督模式和机器模式，它们以等级结构从低到高排列：

• 用户模式（User Mode，U-mode）：

  • 最低权限，通常用于运行用户应用程序。程序在该模式下无法直接访问硬件资源，只能通过操作系统提供的系统调用接口进行有限的操作。
  • 虚拟化支持：也可在虚拟化环境下运行，虚拟机管理程序可以限制用户模式下的虚拟机行为。

• 监督模式（Supervisor Mode，S-mode）：

  • 中级权限，通常由操作系统内核使用。监督模式允许对硬件资源和内存管理进行更直接的控制，如页表管理和中断处理。
  • 虚拟化支持：可以在虚拟化环境下运行，支持在Hypervisor管理下的操作系统执行。

• 机器模式（Machine Mode，M-mode）：

  • 最高权限，通常由固件或低级系统管理程序使用。该模式具有对所有硬件资源的完全访问权限，负责处理最低级别的系统初始化和管理任务，如启动、异常处理和中断控制。
  • 特殊模式：还有更高的调试模式，但此处不做讨论。调试模式类似于机器模式，但用于硬件调试。

支持的模式组合

RISC-V根据应用场景支持以下几种常见的权限模式组合：

• M模式（仅机器模式）：适用于简单的嵌入式系统，所有任务都在最高权限下运行，不需要复杂的内存保护。
• M + U模式：嵌入式系统中常见的组合，机器模式用于底层管理，而用户模式用于运行普通应用程序，提供了基本的内存保护。
• M + S + U模式：适用于类Unix操作系统（如Linux），在这种组合下，操作系统内核运行在监督模式，用户程序运行在用户模式，实现了虚拟内存管理和多用户隔离。
• M + [V(S + U)]模式：适用于支持多个操作系统和虚拟化的复杂系统，允许多个操作系统在虚拟机管理程序的监督下并行运行。

控制和状态寄存器（Control and Status Registers, CSRs）

每个特权模式都可以访问专门的控制和状态寄存器（CSRs），用于管理模式下的操作。CSRs的访问权限根据运行模式而不同，低权限模式无法访问高权限模式的寄存器，以确保系统的安全性和完整性。

• CSRs的作用：这些寄存器控制处理器的关键操作，如中断使能、内存管理以及时间计数器等。每个特权模式可以有其专属的CSR集合，以保证隔离。
• 多副本CSRs：通常，每个模式都有多个CSR副本或视图，确保不同模式下的操作隔离和安全。

通过这种分层的特权模式和CSR访问机制，RISC-V确保了系统从上电到应用程序执行的每个阶段都受到严格的权限控制，同时支持灵活的虚拟化和多操作系统环境。

Privileged Features: Instructions and CSRs

在RISC-V架构中，特权指令和控制状态寄存器（CSRs）是特权模式下的核心功能。它们允许操作系统和固件有效地管理硬件资源，同时提供安全的多用户和多任务环境。特权指令只能在相应的特权模式（如机器模式或监督模式）下执行，确保系统的控制权不会被低权限的用户模式所滥用。

模式专属指令（Mode Specific Instructions）

RISC-V为机器模式（M-mode）和监督模式（S-mode）定义了一系列特权指令，这些指令扩展了基本的用户模式（U-mode）操作，以便在不同的权限模式下更好地控制系统。

• 特权指令只能在适当的特权模式下执行，低权限模式（如U-mode）无法访问高权限模式的指令。这些指令是为了保证不同模式间的隔离和安全。

所有模式下的指令（All Modes）

1. ECALL：

   • 生成环境调用异常，触发从当前模式到更高特权模式的系统调用。
   • 例如，当用户模式的应用程序需要操作系统的服务时，它会通过ECALL指令请求监督模式处理系统调用。

2. EBREAK：

   • 生成断点异常，通常用于调试。
   • 当程序执行到某个断点时，处理器会捕获断点并进入调试模式。

3. FENCE.I：

   • 同步对内存的更新，确保指令的修改在所有后续指令中可见。
   • 这一指令在多核或并发系统中尤为重要，用于确保不同处理器核心之间的内存一致性。

4. RET：

   • 从指定模式的异常中返回。
   • SRET：用于从监督模式的陷阱或异常中返回。
   • URET：用于从用户模式的异常中返回，通常在N扩展（用户模式异常）被支持时使用。

监督模式（S-mode）和机器模式（M-mode）下的特定指令

S-mode（及M-mode）新增指令

1. SFENCE.VMA：
   • 用于同步虚拟内存的更新。
   • 此指令确保对内存页表的更改在所有处理器核心中都被正确识别，防止出现页面翻译错误。

M-mode新增指令

1. WFI（Wait For Interrupt）：
   • 当前hart进入等待状态，直到有中断需要服务时再恢复运行。
   • 该指令用于节省功耗，通常在低功耗模式下使用，是一个提示性指令，可能被实现为空操作（noop）。

特权指令的作用

特权指令的引入是为了增强RISC-V在特权模式下的控制能力。通过ECALL和EBREAK等指令，用户模式的程序可以请求高权限的服务或在调试时打断程序的执行。而诸如SFENCE.VMA和FENCE.I这样的指令则确保了内存管理和同步操作的安全性和一致性。

特权指令确保了不同模式下的隔离和安全性，同时也增强了处理器对多任务、虚拟化和并发场景的支持，使得RISC-V能够灵活适应各种复杂的系统需求。

Mode Specific CSRs

控制和状态寄存器（Control and Status Registers, CSRs）是RISC-V特权架构中的重要组成部分，它们用于管理处理器的操作模式、硬件资源和系统状态。每个权限模式（用户模式、监督模式、机器模式）都有其特定的CSRs，确保不同权限模式下的任务只能访问与其权限相关的寄存器。

CSR的地址空间和访问机制

• 独立的地址空间：CSRs有自己专用的地址空间，直接通过地址访问。这意味着不同的寄存器集在各模式下有不同的编码和访问方式。

• 每个硬件线程（hart）都有自己的CSRs：每个hart（硬件线程）拥有独立的一组CSRs，通常每个模式拥有多达1000个寄存器，总共4K个CSRs（即1000个寄存器乘以4个模式）。

• 专用操作：CSRs通过特定的操作访问，例如支持原子交换或位设置/清除的指令。这些操作确保了对CSRs的高效读写。

• 模式敏感：CSRs只能被运行在相应或更高权限模式下的代码访问。低权限模式（如用户模式）尝试访问高权限模式（如机器模式）的寄存器时，会触发陷阱（trap），从而保护系统安全。

可选和只读CSRs

许多CSRs是可选的，或者具有可选字段，其行为依赖于具体实现：

• 访问不存在的CSRs会触发陷阱：如果某一特权模式的代码尝试访问一个不存在的CSR，处理器会产生异常。
• 只读寄存器的写操作会触发陷阱：尝试写入只读寄存器时，也会产生异常。不过，如果是只读/读写寄存器中的只读字段，写入操作将被忽略，不会触发异常。
• 可选寄存器的访问：可选寄存器在没有实现时，会读取为零，并且（如果是读写寄存器）忽略写入操作。

这使得系统的实现具有高度灵活性，不同的处理器可以根据需要实现不同的CSRs集，依赖于具体的架构和应用需求。

CSR Address Space

在RISC-V架构中，控制和状态寄存器（Control and Status Registers，CSRs）是用来管理处理器的操作模式、硬件资源和系统状态的核心组件。不同的特权模式下，处理器会使用不同的CSR集，确保权限隔离。CSR地址空间由多层结构组成，遵循特定的编码规则，用于区分不同的模式和寄存器。

CSR地址的编码结构

CSR地址是12位的二进制值，用来标识不同的寄存器。具体的编码结构如下：

1. 高两位[11:10]：用于定义CSR的类型。
2. 中两位[9:8]：用于区分不同的特权模式：
   • 00：用户模式（U-mode）专用的CSRs
   • 01：监督模式（S-mode）专用的CSRs
   • 11：机器模式（M-mode）专用的CSRs
   • 10：为虚拟机管理程序（Hypervisor，V-mode）保留，当前版本尚未实现。
3. 其余位[7:6]：用于标识CSR的具体种类和用途。

通过这种结构，RISC-V的CSR地址可以灵活地支持不同的模式、权限级别和操作需求。

CSR地址空间划分

CSR地址空间分为多个区域，每个区域对应不同的特权模式。根据特定的二进制编码，CSR地址的用途如下表所示：

关键编码细节

1. 0b00MM xxxx xxxx：这些CSR主要供用户模式使用，最低权限，通常用于用户程序的控制状态信息，如性能计数器或用户态的软中断控制等。

2. 0b01MM xxxx xxxx：这些CSR供监督模式和调试模式使用，权限较高，典型的应用是页表管理、内存访问控制和中断处理等。监督模式的操作系统内核可以使用这些CSR来管理用户进程。

3. 0b11MM xxxx xxxx：这些CSR为机器模式（M-mode）专用，权限最高。通常，这些寄存器用于系统初始化、硬件配置以及固件层面的管理。

4. 0b10MM xxxx xxxx：这一段目前保留给虚拟化支持（Hypervisor mode）。虽然当前版本的RISC-V规范尚未全面实现虚拟化，但这一编码区域为将来虚拟机管理程序的功能预留了空间。将来，虚拟机管理程序会通过这些CSR来管理多虚拟机的操作。

特殊类型的CSR

• 只读寄存器（ReadOnly）：某些寄存器是只读的，用于存储系统状态或硬件信息，这类寄存器在低权限模式下也可以读取，但无法被写入。

• 非标准寄存器（NonStandard CSRs）：有些CSR的地址编码不属于RISC-V标准，通常由处理器厂商或特定实现提供。这类CSR通常是硬件优化或扩展功能的一部分，处理器厂商可以根据需要定义。

• 调试模式专用CSR：01 10 开头的CSR是调试模式下专用的，用于在调试环境中保存系统的状态信息并控制调试操作。这些寄存器只有在调试端口连接时才能访问。

错误处理与陷阱机制

• 访问不存在的CSR：如果代码试图访问不存在的CSR，处理器会触发一个陷阱（trap），即系统会捕获这个错误并执行相应的异常处理程序。

• 写入只读CSR：同样，试图写入只读CSR也会触发陷阱，这种机制确保了系统的稳定性，防止低权限模式中的错误操作破坏关键数据。

• 可选CSR：某些CSR是可选的，具体实现时可以有选择地支持这些寄存器。如果某个CSR在实现中不存在，处理器在读取时将返回零，并且在写入时忽略操作。

CSR地址空间通过严格的编码规范，确保了不同特权模式下的CSR访问权限划分。机器模式（M-mode）拥有最高权限，能够访问最广泛的CSR集合，而监督模式（S-mode）和用户模式（U-mode）的权限则逐步递减。这种设计保障了系统的安全性和稳定性，同时为未来的扩展（如虚拟化支持）预留了足够的灵活性。

CSRs and Categories

RISC-V架构中的控制和状态寄存器（CSRs）根据其功能被划分为不同的类别，每个类别负责管理处理器的某一方面操作。CSRs为处理器提供了对硬件资源的精细控制和状态监控，涵盖了从异常处理、内存保护到计时器、调试等多个领域。部分CSR在不同的模式（如M-mode、S-mode、U-mode）下会有各自的副本或复制，这样可以保证不同权限级别的隔离性。

主要CSR类别

1. FP CSRs（浮点运算相关）

   • 这些寄存器主要用于管理浮点操作和状态。它们负责处理浮点运算的异常、舍入模式以及浮点寄存器的状态。
   • 关键CSR名称：
     • Exceptions：用于浮点异常的处理。
     • Rounding_Mode：控制浮点运算的舍入模式。
     • Reg_State：浮点寄存器的状态保存。

2. Information（信息寄存器）

   • 这些CSR保存处理器的厂商信息、架构标识、实现细节以及当前硬件线程的ID。
   • 关键CSR名称：
     • Vendor/Architecture/Implementation：用于识别处理器的厂商、架构版本和实现方式。
     • Thread_IDs：管理多线程或多核心系统中每个hart（硬件线程）的标识符。

3. Protection/Translation（保护和地址翻译）

   • 这些CSR用于虚拟内存的地址翻译和物理内存的保护，特别是在多任务操作系统中，保证不同任务之间的内存隔离。
   • 关键CSR名称：
     • Address_Translation_Protection：控制虚拟地址到物理地址的翻译，并应用内存保护。
     • PhysMemProtection Config[]/Addr[]：管理物理内存保护的配置和地址。

4. Trap Setup（陷阱设置）

   • 这些寄存器用于设置和配置异常（trap）的行为，例如指定异常向量地址或启用特定类型的异常处理。
   • 关键CSR名称：
     • Status：保存处理器的当前状态，如当前运行模式、全局中断使能等。
     • Trap_Vector：指定异常处理程序的入口地址。
     • Int_Enable：启用或禁用中断。
     • Cntr_Enab：启用或禁用特定的计数器功能。

5. Trap Handling（陷阱处理）

   • 这些CSR用于处理异常事件，包括保存异常发生时的处理器状态和异常的原因。
   • 关键CSR名称：
     • Exception_PC：保存异常发生时的程序计数器（PC）值，以便在异常处理完成后返回。
     • Scratch：用于异常处理中的临时数据存储。
     • Int_Pending：记录当前待处理的中断。
     • Trap_Cause/Value：保存异常的原因和相关数据。

6. Counter/Timers（计数器和计时器）

   • 这些寄存器用于记录处理器的周期数、时间以及指令执行情况，通常用于性能监控和系统调度。
   • 关键CSR名称：
     • Cycles：记录处理器执行的时钟周期数。
     • Time：用于记录处理器的运行时间。
     • Inst_Retired：记录处理器已执行的指令数。
     • PerfmonCntr[]：性能监控计数器，用于跟踪性能指标。

7. Counter Setup（计数器设置）

   • 用于配置性能监控事件，选择哪些事件需要计数。
   • 关键CSR名称：
     • Perfmon Event selector[]：性能监控事件的选择器。

8. Debug/Trace（调试与跟踪）

   • 这些寄存器用于系统的调试和跟踪功能，帮助开发者分析程序执行情况和定位问题。
   • 关键CSR名称：
     • Control/Status/PC/Scratch：调试模式下的控制与状态寄存器，用于保存调试过程中的状态。
     • Trigger_RegSelect/Data[]：调试触发器寄存器，用于调试时设置条件断点或数据监控。

Memory Addressing: Translation

在RISC-V架构中，虚拟内存是监督模式（S-mode）下的重要功能，它通过页表机制将虚拟地址映射到物理地址，为多进程操作系统提供内存隔离和保护。虚拟内存的引入允许用户模式下的程序拥有各自独立的地址空间，避免直接访问物理内存，从而提升系统的安全性和稳定性。

S-mode中的虚拟内存页映射

• 最小保护/映射单位是4 KB的页面：
  • RISC-V的虚拟内存使用固定大小的页面来进行地址映射，通常情况下每个页面大小为4 KB。4 KB是虚拟内存映射的最小单位，也是分页机制的基本单位。

多用户进程支持

• 支持多个用户模式进程，分别拥有独立的地址空间：
  • 通过使用SATP（Supervisor Address Translation and Protection）CSR中的Addr_Space_ID字段，RISC-V能够为每个用户模式进程分配独立的地址空间。这使得多个进程可以安全并行运行，而不会互相干扰或影响彼此的数据。

页表（Page Tables）的多级结构

RISC-V采用了多级页表机制来实现虚拟地址到物理地址的映射。这种分层结构的页表能够有效管理大量内存，同时支持不同的虚拟地址长度和物理地址长度。

• 页表级数：
  • Sv32（32位架构）：使用2级页表，适用于RISC-V的32位架构（RV32）。
  • Sv39、Sv48（64位架构）：分别使用3级或4级页表，适用于RISC-V的64位架构（RV64）。这些页表机制允许处理更大的内存空间。
  • Sv57、Sv64（保留机制）：这两个机制保留用于未来可能的更大虚拟地址或物理地址空间（如57位或64位地址空间的处理器）。

超大页面（Superpages）

• 页表遍历可以在任意级别停止以创建超级页：
  • 在RISC-V中，超级页是比4 KB常规页更大的内存页块。通过在不同层级的页表遍历中提前停止，可以实现超级页的映射。
  • 例如：
    • 在Sv39架构下，如果页表遍历在第2级停止，可以映射2 MB的超级页。
    • 如果遍历在第1级停止，则可以映射1 GB的超级页。
  • 超级页的存在显著减少了页表项的数量，优化了大数据集或大内存应用的内存管理。

硬件页表遍历机制

• 硬件页表遍历语义由特权模式规范（Privileged Mode Spec）定义：
  • RISC-V硬件负责自动遍历页表以进行地址转换。硬件会按照特权模式规范中定义的方式，逐级遍历页表项来完成虚拟地址到物理地址的映射。
  • 如果硬件无法完成页表遍历，可能会触发陷阱（trap），并进入机器模式（M-mode）以进行软件方式的TLB（Translation Lookaside Buffer）重填。

RISC-V Page Table Entries (PTEs)

可参见 Lzzs 6.S081 Notebook: Page Tables

在RISC-V虚拟内存机制中，页表条目（Page Table Entries, PTEs）负责将虚拟地址映射到物理地址，并定义了每个内存页面的权限和状态。每个PTE包含多个字段，这些字段共同决定内存访问的规则、状态和权限。根据虚拟地址的格式（如Sv32、Sv39、Sv48或Sv64），PTE的结构可能有所不同。

页表条目的结构

以下是以Sv32格式为例的页表条目（PTE）结构，其字段解释如下：

• PPN（物理页面号，Physical Page Number）：用于指定映射的物理页面地址。

  • PPN[1] 和 PPN[0] 是物理地址的一部分。PPN字段可以根据虚拟地址空间的大小有不同的长度，比如Sv32、Sv39、Sv48和Sv64的长度各不相同。
  • PPN字段在最终的物理地址形成中起关键作用，它决定虚拟地址指向的物理内存块。

• RSW（保留位，Reserved for Supervisor）：这些位由操作系统内核自行使用，不会被硬件直接处理。通常用于页表管理和内存分配的额外元数据。

• D位（Dirty）：标识页面是否被写入过。

  • 如果页面被修改过，D位会被设置为1，表示该页面已经“脏”，需要同步回主存。
  • 如果没有设置，可能需要陷阱（trap）到软件层进行处理。

• A位（Accessed）：标识页面是否被访问过。

  • 当该页面被读取或写入时，A位会被设置为1，用于管理页面的生命周期或优化内存交换策略（如LRU）。
  • 如果A位未设置，也可能触发陷阱处理。

• G位（Global）：指示该映射是否在所有地址空间中全局可见。

  • 如果该位设置为1，则此映射对于所有进程都是全局有效的（如Unix系统中的内核页面），在进程切换时不需要刷新TLB。

• U位（User）：控制页面是否可被用户模式访问。

  • 如果设置为1，用户模式代码可以访问该页面。
  • 如果为0，则该页面只能被更高权限的模式（如S-mode或M-mode）访问。

• X位（Execute）：控制页面是否可被执行。

  • 设置为1时，页面上的内容可以作为指令执行。
  • 如果为0，则不允许执行，防止代码注入或其他安全风险。

• W位（Write）：控制页面是否可写。

  • 设置为1时，允许对页面进行写操作；否则，写操作将被禁止。

• R位（Read）：控制页面是否可读。

  • 设置为1时，允许读取页面内容；否则，读取操作将被禁止。

• V位（Valid）：指示该页表项是否有效。

  • 如果V位为0，则该页表项无效，访问该页面时会触发异常。

页粒度的权限设置

• 权限（User/Read/Write/eXecute）：RISC-V PTE支持按粒度设置页面的用户权限，包括读、写和执行权限。如果某个页表条目未设置任何权限位（即000），则该页表项表示为非叶子节点，指向下一层页表。

多地址空间的支持

• Addr_Space_ID（地址空间ID，ASID）：用于支持多进程系统。每个进程的地址空间都有独立的ASID字段，存储在SATP（Supervisor Address Translation and Protection）CSR中。SATP管理当前虚拟地址的宽度、当前进程的ASID以及页表根地址。

多级页表的遍历

根据不同的虚拟地址长度，RISC-V支持不同级数的页表。以Sv64为例，PTE的格式适配64位虚拟地址，在SATP中包括44位的页表根物理地址、16位的ASID和4位的模式字段。

Memory Fences: More Control

内存屏障（Memory Fences）在多处理器系统中确保不同处理器核之间的内存访问顺序一致性。RISC-V引入了SFENCE.VMA指令，用于同步内存结构的更新，特别是页表。

SFENCE.VMA 指令

• S-mode下的SFENCE.VMA：这条指令用于同步虚拟内存数据结构的更新，特别是在修改页表之后，确保新的页表项能够被处理器正确使用。
  • 作用范围：
    • 可以作用于所有页表级别，或者只影响与特定地址相关的级别。
    • 可以作用于所有地址空间，或者仅影响当前地址空间。

页表同步与TLB刷新

• 类似于其他架构的TLB刷新：在许多处理器架构中，当页表发生变化时，需要刷新TLB（Translation Lookaside Buffer，翻译后备缓冲区），以避免旧的映射被继续使用。RISC-V通过SFENCE.VMA实现这一功能。

确保指令顺序

• 确保存储操作有序：SFENCE.VMA可以确保所有先前的存储操作在后续的隐式内存访问前完成，防止出现内存顺序紊乱的情况。

影响范围

• 仅影响本地hart（硬件线程）：SFENCE.VMA指令只影响发出指令的当前hart。如果需要与其他hart同步，通常通过IPI（Inter-Processor Interrupt）进行通知。

SFENCE.VMA 和 FENCE.I 都是RISC-V架构中用于处理内存同步和一致性的指令，但它们的作用和使用场景有所不同。让我们详细对比它们的功能与用途，并解释为什么在操作系统（如xv6）中会用到FENCE.I作为内存屏障。

1. SFENCE.VMA：虚拟内存的同步

• 全称：Supervisor Fence Virtual Memory Address

• 作用：用于同步虚拟内存的页表更新。具体来说，当修改页表（例如创建新的页面映射或释放旧页面）后，需要通过SFENCE.VMA指令来确保这些修改对处理器的地址翻译单元（如TLB，Translation Lookaside Buffer）可见。

• 使用场景：

  • 当操作系统更新页表或修改虚拟内存结构时，必须确保这些更新被所有内存操作正确识别。在不执行SFENCE.VMA的情况下，TLB可能仍然保留旧的虚拟地址到物理地址的映射，导致系统使用过时的数据。
  • SFENCE.VMA通常由内核代码调用，用于清除当前硬件线程（hart）中与虚拟地址相关的TLB条目，确保地址翻译映射的正确性。

• 示例：如果操作系统为进程分配了新的内存页面或者进行了页表的切换（例如，切换到一个新的进程地址空间），SFENCE.VMA指令会确保处理器清除缓存的旧地址映射，并使用新的页表。

2. FENCE.I：指令缓存的同步

• 全称：Fence Instruction

• 作用：FENCE.I用于同步指令缓存（I-cache）与内存。当在内存中修改了代码（例如动态加载新代码或自修改代码的场景），FENCE.I指令确保指令缓存中的旧指令被清除，并强制处理器从内存中重新加载最新的指令。

• 使用场景：

  • 当内存中存储的指令被修改后，指令缓存和内存之间可能会不一致。为了确保处理器执行最新修改的指令，必须使用FENCE.I，清除缓存并刷新指令流。
  • FENCE.I 通常用于内存中的代码被动态修改的场景。例如，操作系统在某个位置加载了一段新的代码，这时就需要使用FENCE.I来保证处理器看到的是最新的代码。

• 示例：在操作系统xv6中，使用FENCE.I指令作为内存屏障，确保处理器在加载新指令后执行正确的指令流。特别是当进程从用户模式切换到内核模式，或者当处理器加载新的用户态代码后，使用FENCE.I可以避免执行缓存中的旧指令。

两者的主要区别

功能/特性	SFENCE.VMA	FENCE.I
目的	用于同步页表更新，清除TLB中的旧虚拟地址到物理地址映射	用于同步指令缓存，确保指令缓存与内存的一致性
影响范围	虚拟内存（页表和TLB）	指令缓存
使用场景	当页表更新或地址空间切换时使用	当内存中的指令被修改或动态加载代码时使用
触发对象	内存地址映射的变化（如进程切换、页表修改）	内存中代码修改或动态生成代码的场景
影响对象	影响当前hart的虚拟地址空间翻译	影响当前hart的指令缓存

为什么xv6使用FENCE.I?

在操作系统（如xv6）中，通常有一些场景需要动态修改内存中的指令，或者加载新的程序代码到内存中。此时，为了确保处理器执行的是内存中的最新代码，而不是已经缓存的旧指令，必须使用FENCE.I来刷新指令缓存，保证代码的正确性。例如，当xv6从内核模式切换到用户模式，或者从磁盘加载新的程序时，FENCE.I确保处理器执行的指令是最新加载的。

SFENCE.VMA 则更多用于处理虚拟地址映射的变化。如果xv6进行页面映射的更改，或切换到新的地址空间，它则会用到SFENCE.VMA。

Memory Addressing: Protection

RISC-V特权架构中的虚拟内存保护机制通过设置每个页面的权限来保证系统的安全性和稳定性。虚拟内存的保护不仅包括传统的读、写、执行（RWX）权限，还引入了针对不同特权模式的访问控制，从而确保内核与用户进程之间的隔离。

页面权限（RWX）

• 标准的RWX权限：每个虚拟内存页面可以配置读（R）、写（W）、执行（X）权限组合。这样做确保了特定页面的访问权限明确，可以精细控制哪些页面可以被读取、写入或执行。
  • 支持执行权限单独设置（X-only pages）：可以将页面设为只允许执行（X-only），这对于一些存储代码但不需要写入的页面很有用。
  • 写和非读（W和非R）的组合被保留：在当前架构中，不允许页面被设置为可写但不可读。这种组合通常没有实际应用，并且可能导致安全漏洞，因此在设计中被保留未使用。

监督模式（S-mode）的内存访问限制

• 默认情况下，S-mode不能访问用户模式（U-mode）的页面：
  • 这种设计有助于检测操作系统或驱动程序中的潜在错误，并确保用户进程与内核的隔离。
  • 如果S-mode需要读取用户内存（例如处理系统调用时），可以通过设置sStatus寄存器中的"Supervisor Access to User Memory"（SUM）位来暂时允许S-mode访问用户内存。
    • SUM位的设置过程是暂时的，S-mode读取用户内存后，应立即关闭此权限，确保安全性。
  • S-mode无法从U-mode页面执行代码，即使SUM位被设置为1。这种设计防止了潜在的权限升级攻击。

执行页面的保护

• S-mode默认不能读取只执行（execute-only）页面：
  • 执行权限和读取权限是独立设置的，S-mode无法读取仅设置了执行权限的页面。这样可以防止未经授权的内核代码试图读取用户模式中的代码页面内容。
  • 如果必须读取执行页面（例如非法指令陷阱处理程序需要读取指令内容），可以通过设置sStatus寄存器中的“Make eXecutable Readable”（MXR）位来覆盖默认行为。

虚拟内存的启用与禁用

• S-mode可以启用或禁用虚拟内存（VM）：通过控制SATP（Supervisor Address Translation and Protection）寄存器中的模式字段，S-mode可以选择启用或禁用虚拟内存管理（例如在嵌入式系统或裸机环境中可能不需要虚拟内存）。
• 选择页表的深度：S-mode还可以通过SATP寄存器选择页表的深度，以适应不同的地址空间需求。例如，使用Sv32、Sv39或Sv48的多级页表结构来管理不同大小的虚拟地址空间。

RISC-V Physical Memory Protection Unit (PMP)

物理内存保护单元（PMP）是RISC-V架构中的一个可选特性，用于在硬件级别对物理内存进行访问控制，特别是在处理器的监督模式（S-mode）或用户模式（U-mode）下，这对于未受信任的操作系统和进程至关重要。PMP的主要作用是通过定义物理内存的权限，来限制访问，并防止未经授权的代码操作敏感的内存区域。

PMP的功能和特性

1. 可选的新特性（v1.10）：

   • PMP是从RISC-V的v1.10版本引入的，作为一个可选的特性，允许系统在硬件层面上控制对物理内存的访问。

2. 默认无权限：

   • 在启用PMP的情况下，默认情况下，监督模式（S-mode）和用户模式（U-mode）对物理内存没有任何权限。PMP通过明确授予读、写、执行（RWX）权限来决定哪些内存区域可以被访问。

3. R/W/X权限配置：

   • PMP允许为多达16个PMP区域设置读、写、执行权限，每个区域可以设置不同的权限组合。
   • 这些区域是以自然对齐的2^N字节（N>=2）为单位的连续内存块，PMP使用这些内存块来定义特定的内存访问规则。
   • 也可以通过相邻的PMP寄存器组合来形成基址/边界（base/bounds）的区域，以灵活设置更复杂的内存访问规则。

4. PMP可以被锁定：

   • PMP区域一旦被配置，可以通过设置为“锁定”，即使是机器模式（M-mode）也无法更改，除非系统进行复位（reset）。
   • 锁定机制确保了在某些关键应用场景下，重要的内存访问权限不会被意外或恶意修改。

5. 虚拟内存与PMP的优先级：

   • 当虚拟内存（VM）启用时，虚拟内存的页表和缺页处理会在PMP检查之前发生。这意味着如果虚拟地址映射失败或者发生缺页错误，PMP检查不会继续。
   • 这种机制对于不受信任的监督模式（S-mode）特别有用，PMP可以作为额外的保护层。

使用场景

• 未受信任的S-mode：在安全敏感的场景下，PMP可以防止不受信任的操作系统（或S-mode应用）访问物理内存中的关键资源，例如固件、特权数据等。
• 嵌入式系统和安全关键系统：PMP在没有复杂虚拟内存机制的情况下，仍然提供了对物理内存的保护，特别适用于嵌入式系统、物联网设备等。

Physical Memory Attributes (PMA)

物理内存属性（PMA）是RISC-V体系结构中用于管理物理地址空间的访问属性的硬件特性。这些属性是平台和实现特定的，这意味着它们由具体的硬件平台决定，而不是RISC-V架构标准中的固定部分。PMA定义了内存访问的各种行为，如访问宽度、对齐限制、可缓存性等。

PMA的功能和特性

1. 平台和实现相关：

   • PMA的配置因具体平台而异。不同平台可能有不同的总线事务类型和内存访问限制。例如，在某些嵌入式系统中，特定的内存地址可能映射到外设，而在另一些平台上则可能是系统内存。

2. 映射到总线事务类型或错误：

   • PMA会将内存访问映射到特定的总线事务类型（例如内存读取、内存写入、设备访问等），或者返回一个错误，指示该访问是不被允许的。

3. 专用硬件控制：

   • PMA由专用硬件单元管理，该硬件负责将特定的物理地址范围映射到相应的访问属性。以下是一些常见的物理内存属性：
     • 访问宽度：支持的访问宽度可以是1/2/4/8/16/64字节等，决定每次内存访问的最小/最大数据块大小。
     • 对齐限制：可能要求内存访问不能跨越特定字节边界（例如2^N字节对齐）。
     • 幂等性（Idempotency）：指在启用推测执行时，允许对某些地址进行重复访问，而不会改变其结果。
     • 内存访问顺序：强顺序或弱顺序控制（Strong/Weak Ordering），用于确保不同通道的内存操作顺序一致性。
     • 缓存行为（Cacheability）：决定特定的内存区域是否可以被缓存（包括写穿、写合并等缓存策略）。
     • 优先级：当多个请求同时访问内存时，可以根据优先级控制冲突时的处理顺序。
     • 原子性：定义是否允许特定类型的原子操作，如交换、逻辑操作、加法等。
     • 允许的访问模式：定义不同的访问模式，如M-mode、S-mode、U-mode、调试模式等是否可以访问特定内存区域。

4. 部分属性可配置：

   • 虽然PMA的部分行为是由硬件固定的，但有些属性可以通过软件配置。这使得系统在运行时可以根据需求调整内存的访问行为。

使用场景

• 内存映射设备：PMA非常适用于嵌入式系统和SoC架构，其中一部分内存空间被映射为外设的寄存器，通过PMA可以为这些地址设置不同的访问权限和行为。
• 缓存控制：PMA允许为不同的内存区域指定缓存策略，特别是在多核处理器或需要处理外部设备的情况下，决定哪些数据应该缓存以及缓存的策略（如写回、写穿等）是非常重要的。
• 系统优化与安全：通过设置访问顺序、优先级和对齐要求，PMA可以提升系统性能，并且通过严格的访问控制可以增强安全性。

Trap Handling: Exceptions and Interrupts

可参见 Lzzs 6.S081 Notebook: Page Faults、Interrupts

在RISC-V架构中，陷阱（Trap）机制用于处理两类重要的事件：异常（Exceptions） 和 中断（Interrupts）。这两类事件的发生方式和处理机制稍有不同，但它们的处理流程在硬件层面是相似的。

异常（Exceptions）与中断（Interrupts）的区别

1. 异常（Exceptions）：

   • 异常是同步事件，它们由具体指令的执行引发。通常，异常是在指令执行过程中检测到错误（如非法操作码、除零错误、内存访问违规等）时触发的。
   • 示例：当程序试图执行一条未定义的指令时，处理器会触发一个异常并进入异常处理程序。

2. 中断（Interrupts）：

   • 中断是异步事件，它们与当前执行的指令无关。中断通常由外部设备（如I/O设备、定时器）或者来自其他处理器核心的信号引发。
   • 示例：当定时器超时时，系统会触发一个中断，处理器暂停当前执行的指令并处理定时器中断。

统一的陷阱处理流程

尽管异常和中断的触发机制不同，它们在RISC-V中通过类似的陷阱机制来处理。

• 陷阱处理的基本流程：

  1. xTVEC CSR：保存陷阱处理程序的入口地址。无论是异常还是中断，处理器都会根据xTVEC的值跳转到相应的处理程序。

     • 中断可以根据xCause的值选择一个可选的偏移量，通过xTVEC + 4 * xCause来跳转到不同的处理程序。

  2. xI/DELEG CSR：用于选择陷阱处理的模式。这个寄存器决定了发生的异常或中断应该陷入哪个特权模式。例如，操作系统可以配置某些中断直接由用户模式处理，而无需进入内核模式。

  3. xCause CSR：保存引发陷阱的原因。

     • 高位（MSB）用于区分这是中断还是异常。
     • 低位（LSB）保存具体的中断或异常编号，标识是什么原因引发的陷阱。

  4. xTVAL CSR：保存额外的关于陷阱的信息，例如非法地址或非法操作码的值。对于某些异常（如非法内存访问），xTVAL可以保存发生错误的虚拟地址。

  5. xEPC CSR：保存导致陷阱的指令的程序计数器（PC）值。陷阱处理程序完成后，处理器将从xEPC中存储的PC地址继续执行，可能是中断处理后的下一条指令，或者重试之前的指令（异常处理）。

  6. xSTATUS CSR：保存处理器的当前状态，包括当前模式（用户、监督或机器模式）以及中断使能位。处理器在进入陷阱处理程序时会自动保存这些状态，以便在处理完成后正确返回。

     • 当陷阱处理完成时，xSTATUS[IntEn]位会被清除，确保处理器在恢复时不会发生竞态条件。

更详细的陷阱处理机制

1. 陷阱处理的位置（Where to trap）：

   • 处理器会根据xTVEC CSR的值找到陷阱处理程序的入口地址。处理器可能跳转到一个固定的处理程序地址，也可能根据不同的原因（xCause）偏移跳转到不同的处理程序。

2. 陷阱的处理模式（Mode to trap into）：

   • 不同的中断或异常可以配置为陷入不同的特权模式（如U-mode、S-mode、M-mode）。这些模式的选择由xI/DELEG寄存器决定，操作系统可以根据需要配置哪些陷阱直接进入用户模式处理，哪些需要更高权限的模式来处理。

3. 陷阱原因（Reason for trap）：

   • 处理器会在xCause CSR中保存引发陷阱的具体原因。这一原因可能是中断（如外部设备中断）或者异常（如非法指令）。xCause还用于区分不同的中断或异常源，以便跳转到不同的处理程序。

4. 返回机制（How to return from trap）：

   • 在陷阱处理完成后，处理器会从xEPC CSR保存的程序计数器继续执行之前被中断的程序。xEPC保存的是引发陷阱的指令地址，而处理器可以通过恢复xSTATUS CSR的状态确保正确的执行模式和中断状态恢复。

异常与中断的处理细节

• 异常的处理：通常是由于指令执行过程中产生的同步错误。处理器会将异常处理程序的入口保存在xTVEC中，并在处理完后根据xEPC返回到同一指令或执行下一条指令。

• 中断的处理：由于中断是异步事件，处理器可以在处理完中断后从xEPC中保存的地址继续执行后续指令。常见的中断包括定时器中断、外设中断或多处理器间的中断（如IPI）。

Trap Setup: Interrupt/Exception Handler Delegation

在RISC-V架构中，陷阱（Trap）通常默认发送到机器模式（M-mode），但为了提高处理效率，某些中断和异常可以被委派到较低的特权模式（如S-mode或U-mode）进行处理。陷阱委派机制允许操作系统根据需求减少开销，同时确保系统的安全性和特权隔离。

委派机制（Delegation Mechanism）

1. 默认发送到M-mode：

   • 在RISC-V架构中，所有的中断和异常默认都会被处理器发送到最高权限的M-mode。这是因为M-mode拥有对系统的完全控制，负责处理所有的低级硬件事件。

2. 委派到低权限模式：

   • 虽然陷阱默认被发送到M-mode，但可以通过设置委派寄存器将某些中断和异常委派到较低的特权模式（如S-mode或U-mode）。
   • 不能将陷阱委派到比触发陷阱的模式权限更低的模式。例如，M-mode的异常可以委派到S-mode，但不能委派到U-mode（除非没有S-mode）。

3. 委派寄存器：

   • mideleg 和 medeleg：这些寄存器控制从M-mode到S-mode的中断和异常的委派。如果没有S-mode（如在嵌入式系统中），可以将陷阱直接委派到U-mode。
   • sideleg 和 sedeleg：在存在S-mode的情况下，这些寄存器用于将中断和异常委派给U-mode，前提是系统启用了N扩展。

4. 中断的启用：

   • 中断的委派只有在对应的启用位（如mie或sie）被设置时才会发生。启用位用于控制中断是否允许处理。
   • 注意：异常总是被启用并处理，无需像中断那样设置启用位。

5. 陷入模式的选择：

   • 委派发生时，中断或异常将被发送到下一级权限模式（M→S，或者S→U）。这可以减轻M-mode的负担，允许低权限模式处理与其相关的事件，例如用户程序引发的异常可以直接在U-mode处理，而不需要进入S-mode。

6. 中断设置CSR位：

   • 当中断或异常发生时，相应的位会在xE/IP CSR（如mip、sip）中被设置，指示当前的中断/异常状态。

Trap Handling: Interrupt/Exception Causes

在RISC-V中，每个中断和异常的原因都存储在xCause CSR中，该寄存器会指示当前发生的中断或异常的类型，便于操作系统采取相应的处理。

xCause CSR 及其功能

1. 原因指示：

   • xCause CSR 保存了中断或异常发生的具体原因。通过该寄存器，操作系统可以知道是哪种类型的事件引发了陷阱，并根据事件类型选择合适的处理方式。
   • 最高位（MSB）用于区分是中断（1）还是异常（0），而低位（LSB）则保存了具体的中断或异常代码。

2. xE/IP CSR 中的位设置：

   • 当一个中断或异常被触发时，对应的位会在xE/IP CSR（如mip、sip）中设置。这个寄存器记录了当前系统中待处理的中断或异常事件，并为系统提供了事件的优先级队列。

3. 同时发生的中断/异常的优先级：

   • RISC-V为同时发生的多个中断和异常设置了优先级规则：
     • 中断优先于异常：当中断和异常同时发生时，处理器优先处理中断。
     • M-mode > S-mode > U-mode：机器模式的中断和异常优先级最高，其次是监督模式，最后是用户模式。
     • Pending[N] > Pending[M] if N > M：较高优先级的中断（如外部中断）优先于较低优先级的中断。

4. 特殊情况：定时器和软件中断：

   • 在某些特定情况下（如定时器中断和软件中断），优先级可能会被交换，以确保系统的定时和内部同步机制不被外部设备的中断打断。

中断与异常的原因代码（Trap Code）

Interrupt

Platform-Level Interrupt Overview

xv6

在RISC-V架构中，中断系统分为全局中断（Global Interrupts）和本地中断（Local Interrupts）。这些中断管理的核心是平台级中断控制器（PLIC），它负责处理和调度外部设备发出的中断信号，并将其分发给系统中的各个硬件线程（harts）。本地中断则直接在每个hart内处理，与定时器和软件中断紧密相关。

全局中断（Global Interrupts）

• 外部中断（External Interrupts）：

  • 全局中断由平台上的外部设备发起，例如外部I/O设备、网络接口或存储设备。这些中断通过PLIC传递给每个hart。
  • PLIC（Platform-Level Interrupt Controller）是RISC-V系统中处理外部中断的核心模块。它接收来自多个外部设备的中断请求，根据中断的优先级和配置决定哪个hart来处理中断。
  • 通过PLIC，每个外部中断被分配给不同的hart（硬件线程），这些中断可以在不同的特权模式（U-mode、S-mode、M-mode）下进行处理。

• PLIC的工作机制：

  • 中断分发：PLIC接收到外部设备的中断信号后，根据中断的优先级和目标hart，将中断传递到合适的hart。
  • 优先级处理：每个外部中断可以被分配不同的优先级，PLIC会根据优先级的高低决定哪个中断优先处理。
  • 中断路由：PLIC负责将外部中断路由到指定的hart和特权模式（U、S、M）。

本地中断（Local Interrupts）

本地中断是与每个hart直接相关的中断，通常涉及到定时器和软件中断。这类中断只影响对应的hart，并不需要通过PLIC进行分发。

• 定时器中断（Timer Interrupts）：

  • 定时器中断是由处理器内部的定时器触发的，用于操作系统的时钟管理或任务调度。这些定时器中断直接分发到对应的hart，不经过PLIC。
  • 每个hart都有自己独立的定时器，这意味着多个hart可以同时处理各自的定时器中断。

• 软件中断（Software Interrupts）：

  • 软件中断通常用于多hart（多核）系统中，hart之间的通信。操作系统可以触发软件中断来通知其他hart执行特定的任务（如任务切换、进程调度等）。
  • 软件中断通过操作系统触发，作用于指定的hart，并由其直接处理。

每个hart的中断处理

每个hart（硬件线程）有自己独立的中断处理机制，并且可以根据特权模式（M-mode、S-mode、U-mode）处理不同级别的中断。每个模式都有自己对应的定时器中断和软件中断。

• M-mode中断处理：M-mode拥有最高优先级的中断处理权力，负责管理最底层的硬件和外部设备的中断。
• S-mode中断处理：S-mode通常用于操作系统内核，用来处理用户进程的调度、虚拟内存管理和设备管理。
• U-mode中断处理：U-mode的中断通常由用户态程序触发，用于软件中断或用户应用程序的定时器管理。

RISC-V Interrupt Source Categories

RISC-V的中断源分为两大类：全局（外部）中断和本地中断。每种中断类型在处理方式和目标硬件上有所不同，并通过特定的机制来分发和处理。

全局（外部）中断

• 路由到hart：全局中断通常来自平台上的外部设备，这些中断由**平台级中断控制器（PLIC）**负责管理。PLIC根据每个hart的中断阈值和优先级，决定将中断路由到哪个hart进行处理。
• 确定中断源：中断源可以通过读取PLIC的MMIO（内存映射I/O）CSR来确定。PLIC负责接收多个外部设备的中断，并根据配置的优先级处理它们。

本地中断

• 本地中断与单个hart相关：本地中断直接连接到每个hart，独立于其他harts。它们不通过PLIC，而是由每个hart自己处理。RISC-V定义了两种标准的本地中断类型：

  1. 软件中断：通常用于hart之间的通信，或由操作系统触发，用于多核系统中的任务调度。
  2. 定时器中断：由定时器触发，用于时间管理或操作系统的时钟调度。

• 通过xCause CSR确定中断原因：本地中断的原因可以直接从xCause CSR中读取。每个hart在接收到本地中断后，可以通过这个寄存器查看具体的中断类型，并进行相应的处理。

任意中断可用于任意模式（M/S/U）

• 中断可指向任何特权模式：无论是全局中断还是本地中断，都可以根据需要分发到任何特权模式（M-mode、S-mode、U-mode）。例如，某些中断可以直接由用户态程序处理，而不需要进入内核模式。
• 同时发生中断时优先级决定处理顺序：当同时发生多个中断时，系统会根据特权模式和中断优先级来决定处理顺序。处理器会首先处理优先级更高的中断。

External Interrupts

外部中断是由系统中的外部设备触发的中断，例如I/O设备、外设或其他硬件模块。这些中断通过PLIC进行管理和分发。

外部中断的工作机制

1. PLIC管理外部中断输入：

   • **平台级中断控制器（PLIC）**接收外部设备的中断请求，并将这些中断分发到合适的hart。PLIC根据hart的中断阈值、中断启用状态以及中断优先级来决定哪些hart处理中断。

2. 多hart的中断目标：

   • PLIC可以将同一个外部中断同时发送到多个hart。在这种情况下，多个hart需要通过仲裁机制来决定哪个hart处理该中断。
   • 仲裁机制：例如，多个hart可以竞争读取映射到PLIC的MMIO寄存器，第一个读取到中断源的hart将负责处理该中断。

3. PLIC的特权模式标签：

   • PLIC可以根据中断的来源和配置，为每个中断输出标记一个特权模式（M/S/U），这允许不同的特权模式处理不同的中断。例如，某些低优先级的外部设备中断可以由用户模式（U-mode）处理，而高优先级中断则交由机器模式（M-mode）处理。

4. 清除外部中断：

   • 外部中断通过MMIO映射的LD（加载）/ST（存储）操作发送到PLIC后，可以通过写入相应的寄存器来清除中断。处理完中断后，操作系统或硬件会通过这种方式通知PLIC，表示中断已完成处理。

5. 软件注入中断：

   • 软件可以直接通过设置SEIP和UEIP中断位来支持PLIC虚拟化。这允许通过软件控制来模拟外部中断，通常用于操作系统的虚拟化环境中，在这种情况下，软件层面可以直接注入中断信号而无需实际硬件设备的中断触发。

Software Interrupts

软件中断是RISC-V架构中hart之间相互中断的机制，通常用于多核处理器中的核间中断（IPI，Inter-Processor Interrupts）。这种机制允许一个hart触发另一个hart的中断，以实现核间的同步或调度。

软件中断的工作机制

1. hart间通信：

   • 软件中断用于hart之间的相互通信。例如，一个hart可以通过发送软件中断来通知另一个hart执行任务或处理事件。这种中断不依赖于外部设备，而是纯粹在处理器内部进行的通信机制。

2. 设置SIP位：

   • 设置某个hart的SIP（Supervisor Interrupt Pending）寄存器位来触发软件中断。这通常通过MMIO写操作实现，即通过内存映射I/O写入来设置目标hart的SIP位，通知它有软件中断需要处理。
   • 如果当前模式（current mode）权限足够（如S-mode或M-mode），hart也可以自行设置其SIP位。

3. 操作系统中的应用：

   • 操作系统或应用程序通常通过ABI/SBI调用来触发hart之间的中断。这些调用可以确保中断请求在虚拟化环境下能够正确传递到目标虚拟hart。
   • 当目标hart处于非活动状态（例如未调度或暂停），中断请求可能会被推迟，直到目标hart再次被调度运行。
   • 在虚拟化环境中，M-mode软件（如监控器或虚拟机管理程序）负责使用**MSIP（Machine Software Interrupt Pending）**寄存器来虚拟化软件中断，确保中断能够在虚拟hart中正确传播。

Timer Interrupts

定时器中断是RISC-V系统中的关键机制，用于管理实时任务调度、操作系统时钟和其他基于时间的操作。定时器中断由硬件定时器触发，并通过MMIO（内存映射I/O）进行管理。

定时器中断的工作机制

1. 单个M-mode 64位硬件定时器：

   • RISC-V系统中通常有一个64位的实时硬件定时器，该定时器为整个系统提供统一的时间基准。这个定时器是所有hart共享的，并不属于特定的hart。
   • 该定时器以固定的速率计数，独立于处理器的时钟速率和功耗管理。

2. 每个hart的时间比较器：

   • 每个hart都有自己的时间比较器（Time Comparator），即mtimecmp寄存器。该寄存器存储一个时间阈值，当定时器的值（mtime寄存器）达到该阈值时，触发hart的定时器中断。
   • 当mtime ≥ mtimecmp时，目标hart的**MTIP（Machine Timer Interrupt Pending）**位被设置，表示该hart的定时器中断需要处理。

3. 定时器和比较器通过MMIO管理：

   • 定时器和时间比较器并不是通过CSR（控制状态寄存器）来控制的，而是通过MMIO地址空间进行读写操作。这意味着操作系统可以通过内存映射的方式与定时器和比较器交互。

4. M-mode负责虚拟化定时器中断：

   • M-mode（机器模式）负责将硬件定时器虚拟化，以支持S-mode和U-mode下的定时器中断。
   • 当较低权限的模式（如U-mode）读取定时器相关的CSR时，操作系统会捕获并通过M-mode进行处理。这样可以确保系统中所有hart能够共享同一个硬件定时器，并且在虚拟化环境中，虚拟机能够使用独立的虚拟定时器。

5. STIP和UTIP的处理：

   • **STIP（Supervisor Timer Interrupt Pending）和UTIP（User Timer Interrupt Pending）**是CSR中的定时器中断位，分别用于监督模式和用户模式下的定时器中断管理。
   • 这些定时器中断通过操作系统（SBI/ABI调用）进行设置，M-mode负责写入和清除这些中断位，确保定时器中断能够及时处理。

Counters: Time and Performance

RISC-V体系结构支持多种计时器和计数器，这些工具主要用于性能监控、调试和时间管理。大多数计时器和计数器在RISC-V中都作为控制和状态寄存器（CSRs）来实现，主要通过特权模式下的访问进行管理。

Timers and Counters

RISC-V架构提供了多个计时器和计数器，用于不同场景的时间管理和性能监控。这些计数器大多数是64位的，在RV32架构下被分成两个32位的寄存器来读取。

1. 实时时钟（Real-Time Clock, Time）：

   • 实时时钟通过特定的CSR记录系统当前的时间。这个计时器的行为在定时器中断部分已经解释过了。
   • 当U-mode（用户模式）或S-mode（监督模式）读取这个CSR时，系统会发生陷阱（trap）进入M-mode，M-mode通过MMIO进行相应的读操作。

2. 指令退休计数器（Instructions Retired, InstRet Counter）：

   • InstRet 计数器记录处理器执行的指令数，通常用于性能分析和调试。U-mode可以只读（RO），M-mode则可以读写（RW）。
   • 操作系统或监控器可以通过伪指令RDINSTRET读取该计数器，用于测量执行的指令数量。

3. 周期计数器（Cycles, Cycle Counter）：

   • Cycle 计数器用于记录处理器自启动以来经过的时钟周期数。和InstRet一样，U-mode可以只读，M-mode可以读写。
   • 伪指令RDCYCLE允许操作系统或应用程序读取该计数器，以测量程序执行所消耗的时钟周期。

4. 硬件性能监视器（Hardware Performance Monitors, HPMCounters）：

   • RISC-V提供了多达30个硬件性能监视器（mhpmcounters），用于监控各种硬件事件，如缓存命中、分支预测失败等。
   • 每个硬件性能监视器都有一个对应的事件选择寄存器（HPMEvent），用来选择该计数器需要监控的硬件事件。用户或系统可以根据需要，设置这些计数器来分析不同的硬件行为。

Timer/Counter Protections

由于计时器和计数器可以用于性能分析和测量，未经限制的访问可能会导致安全性问题，例如侧信道攻击。因此，RISC-V架构提供了对计时器和计数器的保护机制，防止不必要或不安全的访问。

1. 计时器的安全隐患：

   • 可访问的计时器和计数器可能导致问题，包括：
     • 可重复性不足：如果计时器或计数器的访问不可控，可能导致调试结果的不一致性。
     • 侧信道攻击：例如Meltdown和Spectre等攻击可以利用计时器和计数器信息来推断系统内部的状态。因此，限制这些工具的访问权限至关重要。

2. CounterEn寄存器（xCounterEn CSRs）：

   • 通过CounterEn寄存器，RISC-V系统可以控制不同模式下对计时器和计数器的访问权限。
   • 每个计数器有一个对应的控制位：该控制位决定了是否允许某个模式（如M-mode、S-mode或U-mode）访问特定的计时器或计数器。
     • 计时器（Time）、周期计数器（Cycle）、指令退休计数器（InstRet）以及硬件性能监视器（HPMCounters）都受到此机制的保护。
   • 如果在某个模式下访问了被禁止的计时器或计数器，处理器将触发陷阱，以确保非法访问不会发生。

3. 可硬连线为0的控制位：

   • 某些计数器的控制位可以在硬件上被设置为永远为0，确保在任何模式下都无法访问这些计数器。这为系统提供了一个额外的安全保护层，防止计数器被恶意使用。

Some Additions

<x>Status CSR 寄存器详解

RISC-V架构中的<x>Status CSR（控制和状态寄存器）是一个关键的寄存器，用于管理处理器的运行状态。不同的特权模式（如M-mode、S-mode、U-mode）都有各自的<x>Status寄存器，例如M-mode使用mstatus，S-mode使用sstatus，U-mode使用ustatus。这个寄存器的不同位控制着处理器的特权模式切换、异常处理、中断启用等行为。

寄存器位定义

该寄存器的每个位都有特定的功能，从低位到高位的主要字段如下：

1. 中断控制位（Bits 0-3, 7-11）

• IE（Interrupt Enable，位0）：控制当前模式下的全局中断使能。如果该位被设置为1，则当前模式允许中断；否则，当前模式下中断被禁用。
• PIE（Previous Interrupt Enable，位4）：在中断发生前记录的中断使能状态。当中断返回时，这个位的值会恢复到IE位中，确保处理器在中断返回时能够恢复中断前的中断使能状态。
• SIE、UIE：分别为监督模式和用户模式的中断启用控制位，类似于M-mode的IE位功能。
• SPIE、UPIE：记录S-mode和U-mode下的上一次中断使能状态，处理机制类似于M-mode。

2. 特权模式切换字段（Bits 11-12, 13-14）

• MPP（位11-12）：记录M-mode之前的特权模式，用于异常处理返回时恢复正确的模式。可能的值包括：
  • 00: U-mode
  • 01: S-mode
  • 11: M-mode
• SPP（位8）：在S-mode下，记录之前的特权模式。当从S-mode返回时，根据该位的值决定返回U-mode还是S-mode。

3. 特权模式中断相关字段（Bits 15-16）

• XS（位15-16）：表示扩展状态的清洁度，主要用于浮点扩展或其他处理器扩展：

  • 00: 无状态
  • 01: 有扩展，但初始状态
  • 10: 清洁状态
  • 11: 脏状态（已被使用）

• FS（位13-14）：表示浮点寄存器的状态和是否被使用：

  • 00: 浮点单元未启用
  • 01: 浮点单元被初始化，但未使用
  • 10: 浮点单元已清洁，但可能使用过
  • 11: 浮点单元已脏，正在使用

4. Supervisor模式控制位（Bits 18-21）

• SUM（位18）：当此位被设置为1时，S-mode允许访问U-mode的页面。当设置为0时，S-mode无法访问U-mode页面。这有助于保护用户态的内存不被内核意外访问。
• MXR（位19）：允许S-mode加载执行权限为只读的页面。这个位为某些加载代码段提供了灵活性。
• TVM（位20）：当设置为1时，S-mode无法修改虚拟内存页表（如SFENCE.VMA指令将陷阱到M-mode）。该位用于限制S-mode对虚拟内存的直接访问。
• TW（位21）：当设置为1时，S-mode的WFI指令会触发陷阱，避免内核等待可能导致的延迟。

5. S-mode扩展位（Bits 32-35, 63）

• SXL、UXL（位32-35）：控制S-mode和U-mode的XLEN（操作位宽，如32位、64位）。这允许处理器在S-mode或U-mode下选择适当的位宽。
• SD（位63）：表示扩展状态是否被修改，如果设置为1，说明浮点、扩展状态寄存器（如FS、XS等）已经被使用并且是“脏”的。

6. 其他字段

• TSR（位22）：如果设置为1，SRET指令在S-mode执行时会陷阱到M-mode。此字段用于控制S-mode返回机制。
• TW（位21）：当设置为1时，WFI指令在S-mode下会触发陷阱，防止S-mode中执行WFI导致的长时间等待。
• MPRV（位17）：当设置为1时，处理器在M-mode下使用当前的特权模式进行加载/存储操作。

特别注意

• 清除/设置位：一些寄存器位在不同模式下读回0值。例如，当在U-mode下读取特定的S-mode或M-mode相关字段时，这些位会被读取为0。
• 高位的SD字段：此字段会标记浮点或其他扩展状态是否已被使用（"脏"），并且影响处理器对这些扩展状态的保存与恢复操作。

RISC-V的控制和状态寄存器（CSRs）、特权模式和选项

RISC-V架构通过**控制和状态寄存器（CSRs）**来管理处理器的运行状态、特权模式之间的切换，以及各种硬件资源的使用。不同的CSRs有特定的访问权限，只有在适当的特权模式下才能读写。以下是常见的CSRs分类及其在各特权模式（M-mode、S-mode、U-mode）中的可用性和作用。

1. 浮点控制寄存器（Floating-Point CRs）

• 这些寄存器用于浮点单元（FPU）的控制和状态存储，适用于实现了浮点扩展的系统。
• Accrued Exceptions、Dynamic Rounding Mode 和 Control & Status寄存器均在M-mode、S-mode和U-mode中可用，默认（DF）情况下可以访问。
• 这些寄存器通常与浮点运算密切相关，控制浮点计算时的舍入模式、异常等。

2. 信息类寄存器（Information）

• 包含处理器的供应商、架构ID、硬件实现信息、以及硬件线程ID等。
• Vendor ID、Architecture ID、Implementation ID、Hardware Thread ID 等信息寄存器通常只能在M-mode中读取。它们提供了有关处理器的硬件规格信息，帮助操作系统识别平台。
• Hardware Thread ID 对于hart 0 是必须存在的，其他harts可能根据实现而定。

3. 陷阱设置寄存器（Trap Setup）

• 这些寄存器用于设置和管理异常或中断的处理。
• Status CSR：记录当前处理器状态，可在所有特权模式下访问，但访问权限和可见字段根据特权模式有所不同。
• Exception Delegation、Interrupt Delegation：用于将异常和中断委派给较低权限的模式（例如，将M-mode的陷阱委派给S-mode），这些寄存器通常仅在M-mode下使用。
• Interrupt Enable 和 Trap Vector Base Address：分别控制中断使能和陷阱向量的基地址。在M-mode、S-mode中都可访问，但某些位可能是只读的。
• Counter Enable：决定是否允许较低模式访问计数器（如时间计数器、周期计数器）。

4. 陷阱处理寄存器（Trap Handling）

• 用于处理异常和中断，保存相关信息，以便在陷阱发生时进行正确的处理。
• Scratch Register：用于存储处理器在陷阱处理过程中的临时信息，各模式均可访问，但访问权限不同。
• Exception Program Counter（EPC）：存储触发异常或中断的指令地址。
• Trap Cause：标识异常或中断的原因。
• Trap Value 和 Interrupt Pending：存储陷阱相关的其他信息，包括中断挂起状态。
• 这些寄存器在M-mode和S-mode下可用，在U-mode下通常只读（RO）。

5. 内存保护和地址翻译（Protection/Translation）

• 包括物理内存保护（PMP）和虚拟内存地址翻译功能，主要用于管理处理器访问内存时的权限和映射。
• Physical Memory Protection Config 和 Physical Memory Protection Address：用于配置物理内存的保护策略，防止未经授权的访问。主要在M-mode中配置。
• 这些寄存器通常在虚拟内存启用时启用，并允许对特定内存区域进行保护设置。

6. 计数器/定时器（Counters/Timers）

• 这些寄存器用于记录处理器的周期、指令计数和时间，主要用于性能分析和系统调度。
• Cycle Counter 和 Time Counter：分别记录处理器运行的时钟周期和系统时间，M-mode可读写，U-mode通常只读。
• Instruction Retired Counter：记录处理器执行的指令数，伪指令RDINSTRET可用来读取。
• Performance Counters（HPM Counters）：用于监控特定的硬件性能事件，具体的性能事件通过对应的HPMEvent寄存器进行选择。M-mode可访问多个性能计数器，而U-mode的访问可能受限。

7. 调试/追踪寄存器（Debug/Trace）

• 这些寄存器主要用于调试目的，帮助开发者捕获处理器的运行状态并追踪问题。
• 包括Debug Trigger Register、Debug Control/Status Register、Debug Program Counter等，用于配置和记录调试器的触发条件和状态。
• 这些寄存器大多只能在M-mode中访问，因为它们与硬件的调试功能紧密相关。

CSR字段类型

不同的CSR字段有不同的访问权限和使用规则，常见的字段类型包括：

• WIRI（Write-Ignored, Read-Ignored）：写入和读取都被忽略。
• WPRI（Write-Preserved, Read-Ignored）：写入后值保留，但读取时忽略。
• WLRL（Write Legal, Read Legal）：合法的读写操作。
• WARL（Write Any, Read Legal）：写入任意值，但读取时返回合法值。

访问模式和选项总结

• M-mode：拥有最高权限，能够访问和修改所有CSRs。
• S-mode：可以访问许多与异常处理、内存管理和计时器相关的寄存器，但某些功能受限于M-mode的设置。
• U-mode：权限最少，通常只能读取特定寄存器，用于应用程序级别的性能监控或时间管理。

这张表提供了一个全面的概览，帮助理解哪些寄存器在不同的特权模式下可用，以及它们的访问权限如何受到限制。这种设计确保了RISC-V在不同特权模式下的安全性，同时提供了灵活的系统配置选项。

Interrupt/Exception Handler Delegation

在RISC-V架构中，中断和异常的处理通常默认在最高特权级别的M-mode（机器模式）进行。但为了提升系统的效率，部分中断和异常可以委派到较低特权模式，如S-mode（监督模式）或U-mode（用户模式），这就是中断/异常处理委派的机制。委派的机制通过特定的控制和状态寄存器（CSRs）来实现，如mideleg和medeleg等。

1. 全局中断使能（Global Interrupt Enable）

全局中断使能位根据当前的特权模式（M-mode、S-mode、U-mode）启用或禁用相应模式的中断处理。

• M-mode中断使能：

  • 全局中断使能条件为 currMode < M，即当前模式的权限低于M-mode。
  • 当前模式为M-mode时，Mstatus.MIE位决定是否启用M-mode的中断处理。如果MIE被设置为1，则允许M-mode中断；否则，M-mode中断被禁用。

• S-mode中断使能：

  • 全局中断使能条件为 currMode < S，即当前模式的权限低于S-mode。
  • 当前模式为S-mode时，Mstatus.SIE位决定是否启用S-mode的中断处理。同样，如果SIE被设置为1，则S-mode中断被启用。

• U-mode中断使能：

  • 全局中断使能条件为 currMode < U，即当前模式的权限低于U-mode。
  • 在U-mode下，Mstatus.UIE控制是否启用U-mode的中断处理。U-mode是权限最低的模式，通常用于用户应用程序的中断处理。

2. 委派机制

委派机制允许将某些中断和异常委派给较低特权的模式处理，减少高特权模式（如M-mode）的处理负担。

• mideleg和medeleg寄存器：用于将M-mode的中断和异常分别委派给S-mode。

  • mideleg：决定哪些中断可以委派给S-mode处理。如果对应位被设置为1，则该中断由S-mode处理；否则由M-mode处理。
  • medeleg：决定哪些异常可以委派给S-mode处理。如果对应位被设置为1，则该异常由S-mode处理；否则由M-mode处理。

• sideleg寄存器：如果S-mode被实现并启用，S-mode也可以进一步将中断委派给U-mode处理。

3. 中断与异常的优先级

RISC-V通过优先级逻辑决定当多个中断或异常同时发生时的处理顺序。优先级从高到低依次为：

• 中断 > 异常：中断的优先级高于异常，系统会优先处理中断。
• M-mode > S-mode > U-mode：高特权模式的中断和异常优先处理。例如，M-mode的中断优先级高于S-mode和U-mode的中断。
• Pending[N] > Pending[M] 如果 N > M：如果中断优先级N大于M，则优先处理中断N。这种机制确保了重要的中断能够优先被响应。

4. 特殊优先级情况

对于定时器和软件中断，在某些特殊情况下，优先级可能会被交换。例如：

• 定时器中断和软件中断的优先级被交换：通常情况下，硬件会根据系统需求调整定时器中断和软件中断的优先级，以确保系统的定时和同步机制不被其他中断影响。

5. Trap处理流程

• 当一个中断或异常发生时，系统首先判断是否启用了中断（由Int Enable位决定）。
• 系统根据优先级逻辑确定处理的模式，并生成相应的Trap，将控制权交给指定模式的中断或异常处理程序。
• 处理器将陷入新的模式（M-mode、S-mode或U-mode），并在Cause寄存器中记录引发Trap的原因。

Interrupt Pending/Enable CSRs (<x>ip, <x>ie)

在RISC-V架构中，中断挂起（Pending）寄存器和中断使能（Enable）寄存器管理着每个硬件线程（hart）的中断状态和中断启用情况。这些寄存器分别是<x>ip和<x>ie，其中<x>代表特定的特权模式，例如m（M-mode，机器模式）、s（S-mode，监督模式）和u（U-mode，用户模式）。这些寄存器与每个hart关联，用于管理不同来源的中断，包括外部中断、定时器中断和软件中断。

1. <x>ip寄存器

• 功能：<x>ip寄存器反映了当前hart的中断挂起状态（Pending）。该寄存器的每一位对应不同类型的中断来源，当中断发生且尚未被处理时，相关位将被置为1。
• 中断源：
  • MEIP（位11）：外部中断，来自PLIC（Platform-Level Interrupt Controller），通过PLIC路由到相应的hart。
  • SEIP（位9）：监督模式的外部中断。
  • UEIP（位8）：用户模式的外部中断。
  • MTIP（位7）：机器模式定时器中断，表示定时器中断挂起。
  • STIP（位5）：监督模式定时器中断。
  • UTIP（位4）：用户模式定时器中断。
  • MSIP（位3）：机器模式软件中断，通常用于hart间通信。
  • SSIP（位1）：监督模式软件中断。
  • USIP（位0）：用户模式软件中断。
• 可见性：特定的中断源可能在某些特权模式下不可见。例如，U-mode中无法看到MEIP和MTIP位。

2. <x>ie寄存器

• 功能：<x>ie寄存器用于启用或禁用各类中断。与<x>ip对应，<x>ie的每一位控制是否允许相关类型的中断被处理。当相应的<x>ie位为1时，中断被允许；为0时，中断被屏蔽。
• 中断使能：<x>ie寄存器控制每个特权模式下中断的启用状态，类似于<x>status中的全局中断使能位，但<x>ie的作用更为精细化，允许为特定类型的中断单独启用或禁用。
• 多级中断管理：M-mode可以管理和启用S-mode和U-mode的中断，S-mode则可以管理U-mode的中断。这种层级化的中断使能机制保证了中断的处理优先级。

3. 中断的处理和委派

• 中断的特权级别区分：RISC-V为每个特权级别提供独立的中断挂起和使能寄存器。例如，M-mode处理与机器模式相关的中断，而S-mode和U-mode处理各自的中断。M-mode可以选择将部分中断委派给S-mode或U-mode进行处理。
• 委派机制：M-mode可以通过mideleg寄存器将某些中断委派给S-mode处理，S-mode也可以进一步将中断委派给U-mode。通常，较高优先级的模式可以控制较低优先级模式的中断处理。

4. 用户模式中断处理（N扩展）

• 如果实现了N扩展（用户模式中断处理功能），则U-mode可以直接处理某些类型的中断，而无需通过S-mode或M-mode。这种情况下，用户模式的中断处理更加高效，减少了特权模式切换带来的开销。

5. 中断优先级与处理顺序

• 中断优先级：RISC-V体系结构规定了中断的优先级，高优先级的中断将优先于低优先级中断。通常，M-mode的中断优先级最高，其次是S-mode和U-mode。
• 优先处理的中断类型：定时器中断、外部中断和软件中断的优先级可以根据系统需求进行调整。例如，定时器中断和软件中断在某些情况下可能交换优先级。

6. 挂起中断的全局管理

• 全局使能条件：中断的处理依赖于多个条件，首先需要通过<x>status中的全局中断使能位（如MIE、SIE、UIE）启用，然后通过<x>ie启用具体类型的中断。只有在全局使能和具体中断类型使能均为1的情况下，中断才会被处理。
• 中断禁用：当当前特权模式低于中断的优先级时，中断将自动禁用。例如，U-mode无法处理M-mode的中断；中断优先级较高的模式将优先处理中断。

PLIC (Platform-Level Interrupt Controller) Block Diagram 详解

RISC-V架构中的平台级中断控制器（PLIC）是用于处理外部中断的关键组件，它负责将来自多个外部设备的中断请求路由到适当的hart（硬件线程）。PLIC可以管理大量的外部中断，并根据中断的优先级、使能状态以及目标hart的配置，选择合适的中断处理顺序。

1. PLIC的主要功能

PLIC的主要功能是根据每个hart的配置，确定最高优先级的挂起中断，并将其传递给目标hart进行处理。每个hart可以通过PLIC控制其中断的处理优先级和使能状态。

2. 中断输入转换（Int Gateway）

每个外部中断源都会通过Int Gateway模块，进行边沿触发、极性和电平的标准化处理。此模块将不同外设设备发出的中断信号转换成一个标准格式，以便PLIC进行后续处理。

3. 中断挂起和优先级管理

• 中断挂起寄存器（Int Pend）：每个中断源都有一个挂起寄存器，用来记录该中断是否处于挂起状态。挂起状态意味着该中断请求已经被发出但尚未被处理。
• 中断优先级寄存器（Int Priority）：每个中断源还有一个优先级寄存器，用来设置该中断的优先级。优先级数值越大，表示该中断的重要性越高。PLIC根据这些优先级来决定哪些中断应该优先处理。

4. 中断使能寄存器（Int Enable）

每个hart可以为各自相关的外部中断配置其中断使能寄存器（Int Enab）。如果某个中断源的使能位被设置为1，则该中断被允许触发处理；否则，即使中断请求挂起，PLIC也不会将其发送到hart进行处理。

5. 优先级比较与中断分配

PLIC为每个hart维护一个当前优先级，并且会根据该hart的最大优先级设置决定处理哪一个中断：

• Max Priority & Associated ID：PLIC会为每个hart查找最高优先级的挂起中断。如果某个挂起中断的优先级高于当前hart正在处理的中断优先级，则PLIC将此中断信息传递给hart。
• 比较过程：在每个hart的中断队列中，PLIC通过优先级比较器（>符号表示）查找最高优先级的中断请求，并根据优先级分配给hart处理。

6. 中断处理流程（for each hart）

PLIC为每个hart执行以下操作：

• 查找最高优先级的已启用中断：遍历每个外部中断源，找到其优先级高于当前hart中断优先级的中断源。
• 将最高优先级的中断发送到hart：如果找到的中断优先级比hart当前处理的中断高，则PLIC将该中断的ID和挂起状态发送到目标hart，hart将开始处理该中断。

7. 每个hart的独立配置

PLIC的结构针对每个hart独立复制一套中断管理逻辑，确保多个hart能够并行处理不同的中断请求。每个hart都有自己的优先级和中断挂起状态，PLIC会根据每个hart的配置进行中断分配。

8. Hart Priority 和中断处理

• 每个hart都有自己的当前处理中断的优先级，如果有新的中断请求且其优先级高于当前优先级，PLIC将会中断当前处理中断，将新的更高优先级的中断传递给hart进行处理。

Hypervisor Mode

RISC-V引入了虚拟机管理程序模式（Hypervisor Mode），以支持虚拟化功能，允许多个操作系统或“客户机”在同一个物理硬件上独立运行。RISC-V的Hypervisor模式主要运行在S-mode（监督模式）下，并通过一系列控制和状态寄存器（CSRs）来管理客户机操作系统的虚拟化资源和权限。

1. 硬件支持虚拟化

• Type-2 Hypervisor：RISC-V的虚拟化功能类似于Type-2虚拟机管理程序，如KVM（Kernel-based Virtual Machine）。Type-2虚拟机管理程序运行在S-mode之上，由操作系统控制，管理多个客户机的虚拟机。
• Type-1 Hypervisor：RISC-V也可以支持Type-1虚拟化，这种类型的虚拟机管理程序直接运行在硬件上，不依赖于操作系统。

2. Hypervisor运行于S-mode

• 虚拟机管理程序（Hypervisor）通常运行在S-mode下，它负责分配物理资源给虚拟机，并管理虚拟机的生命周期和状态。客户机操作系统（Guest OS）则运行在虚拟化后的V-mode下，分别对应虚拟化的S-mode和U-mode。

3. 客户机运行在虚拟化的S-mode和U-mode

• 虚拟化模式（V-mode）：客户机操作系统可以运行在虚拟化的V-S-mode和V-U-mode，这些模式与真实的S-mode和U-mode类似，但由Hypervisor管理。
• 两级页表遍历（2-level Page Table Walk）：客户机操作系统的虚拟内存管理使用两级页表。第一层页表由Hypervisor管理，第二层由客户机管理。这种设计确保了客户机的内存管理受到Hypervisor的严格控制，防止客户机直接访问未经授权的内存区域。

4. 操作的限制与陷阱

某些操作在虚拟化环境中可以被限制或引发陷阱，以便由Hypervisor来处理：

• WFI指令：当客户机运行的WFI（等待中断）指令等待时间超过设定的阈值时，该指令可能会触发陷阱，由Hypervisor处理。
• SRET、SFENCE.VMA、SATP和计数器访问：这些指令和寄存器的访问可以被Hypervisor禁止或设置为陷阱。当客户机试图访问这些资源时，Hypervisor会介入并进行适当的处理。
• 强制使用监督模式的特权级别进行地址转换：Hypervisor可以强制使用S-mode的权限级别进行地址转换，确保客户机无法超越其权限范围访问内存。

5. STATUS CSR中的附加位

• 在虚拟化模式下，STATUS CSR（控制和状态寄存器）添加了额外的位以支持虚拟化功能：
  • Previous Virtualization Mode：用于记录之前的虚拟化模式，便于异常处理时的状态恢复。
  • Translation Fault Level：用于标识地址转换过程中出现的错误级别，帮助Hypervisor诊断虚拟内存管理问题。

6. 控制位的解释变化

在虚拟化模式下，一些控制位的解释方式发生了变化：

• SPRV、SPV和SPP：这些控制位用于指示当前的特权模式和状态，虚拟化模式下的解释可能与非虚拟化模式有所不同。

7. 虚拟化模式（Vmode）的CSR切换与选择

在虚拟化环境中，特权模式的切换可能会引发CSR（控制和状态寄存器）的切换和选择，RISC-V提供了一套专门用于虚拟化的CSR，包括：

• hstatus：用于管理虚拟化状态。
• hedeleg和hideleg：用于委派异常和中断给虚拟化的S-mode或U-mode处理。
• htval：记录虚拟机相关的地址转换错误信息。

同时，以下CSR会在虚拟化模式切换时交换：

• sstatus、sie、sip：监督模式的状态、中断使能和中断挂起寄存器。
• stvec、sscratch、scause：分别为陷阱向量、临时存储和异常原因寄存器。
• sepc、stval、satp：分别为异常程序计数器、异常值寄存器和地址转换寄存器。

内核与应用程序的接口

应用程序与操作系统内核之间的交互接口通常被称为内核的 API（Application Programming Interface）。这一 API 是操作系统为用户空间的应用程序提供的一组服务，它定义了应用程序如何请求内核执行某些任务或获取系统资源。在实际操作中，最常见的这种交互方式是通过 系统调用（System Call）。虽然系统调用表面上与普通函数调用类似，但它本质上更为复杂，因为它不仅涉及到跨越不同权限的边界，还要保证整个系统的安全性和稳定性。

系统调用 是用户空间程序访问内核服务的唯一合法途径。当一个应用程序希望执行诸如文件读写、进程管理或内存分配等操作时，它必须通过系统调用来实现。这是因为用户空间的应用程序被限制在较低权限的用户模式（User Mode）中，无法直接访问硬件资源或修改系统的核心数据。为了确保对系统资源的访问是在受控环境下进行，操作系统通过系统调用将这些敏感操作委托给内核态（Kernel Mode）来完成。

在系统调用执行时，应用程序首先发出请求，处理器随后从用户模式切换到内核模式。此时，操作系统接管控制权，开始执行内核中的代码。内核会检查请求是否合法并根据内核 API 提供相应的服务，比如读取磁盘文件、分配内存、或与外部设备进行通信。完成操作后，处理器会再次切换回用户模式，将控制权交还给应用程序，并返回操作结果。这一过程确保了应用程序只能通过规范的接口访问硬件资源和系统数据，从而防止应用程序直接操作硬件或破坏系统的稳定性。

系统调用的设计目的不仅是为了实现应用程序和内核之间的功能交互，更重要的是为了提供一种安全性机制。通过将用户态与内核态分隔，操作系统可以有效地防止用户程序直接访问或篡改内核数据，避免意外或恶意操作导致系统崩溃。此外，系统调用的这种模式也为系统提供了更高的灵活性，操作系统可以对系统调用的实现进行优化或扩展，而无需改变应用程序的代码。

在本节的后续内容中，我们将深入探讨系统调用的具体实现方式，尤其是在现代操作系统中的工作原理。通过对系统调用的源代码和执行过程的详细分析，我们可以逐步理解操作系统如何为应用程序提供底层支持。同时，我们也会通过实际编程实践，展示如何编写和调用系统调用，进一步了解它们在操作系统中的关键作用。

系统调用的实际例子

在操作系统中，系统调用是用户空间程序与内核交互的关键机制。尽管系统调用在代码中看起来像普通的函数调用，但实际上它们触发了从用户模式到内核模式的切换，从而执行内核中的特定操作。

1. open 系统调用

#![allow(unused)]
fn main() {
// user/src/file.rs
pub fn open(path: &str, flags: OpenFlags) -> isize {
    sys_open(path, flags.bits)
}

// user/src/syscall.rs
pub fn sys_open(path: &str, flags: u32) -> isize {
    syscall(SYSCALL_OPEN, [path.as_ptr() as usize, flags as usize, 0])
}

// os/src/syscall/fs.rs
pub fn sys_open(path: *const u8, flags: u32) -> isize {...}
}

当应用程序需要打开一个文件时，调用 open 系统调用，并将文件名作为参数传递给系统。假设我们需要打开一个名为 “out” 的文件，同时希望对文件进行写操作，可以使用类似以下代码的方式进行调用：

#![allow(unused)]
fn main() {
let fd = open("out", OpenFlags::WRONLY);
}

• "out" 是文件的路径。
• OpenFlags::WRONLY 表示我们希望以只写模式打开文件。

在rCore中，文件的打开过程也是通过系统调用与内核进行交互的，但由于 rCore 使用 Rust 编写，系统调用的接口和内部处理与传统的 C 语言操作系统（如 xv6）有所不同。

系统调用实现（sys_open）

在 rCore 的用户态代码中，sys_open 函数用于封装用户程序与内核的交互。该函数负责向内核发起 open 系统调用，请求内核打开文件并返回文件描述符。

#![allow(unused)]
fn main() {
pub fn sys_open(path: &str, flags: u32) -> isize {
    syscall(SYSCALL_OPEN, [path.as_ptr() as usize, flags as usize, 0])
}
}

• path：文件路径，通过传递字符串引用。
• flags：打开文件的标志位，表示文件的操作模式，例如只读、只写等。
• syscall：这是系统调用的通用接口，它负责通过 SYSCALL_OPEN 系统调用号与内核通信。syscall 函数将 path 和 flags 等参数转换为整数形式传递给内核。
• path.as_ptr() as usize：将文件路径的指针转换为 usize 类型，以便传递给内核。

调用 syscall 后，系统会切换到内核模式，内核接收这些参数，并查找文件的磁盘位置，然后为文件分配一个文件描述符（File Descriptor, fd）。

用户态接口 (open 函数)

在用户程序中，open 函数进一步封装了 sys_open 系统调用，提供了更高层次的抽象，让用户更方便地使用 open 系统调用。

#![allow(unused)]
fn main() {
pub fn open(path: &str, flags: OpenFlags) -> isize {
    sys_open(path, flags.bits)
}
}

• path：文件路径，表示需要打开的文件名。
• flags：这是 OpenFlags 枚举类型，用来指定文件的打开模式，例如只读、只写等。通过 flags.bits 获取具体的标志位值。
• sys_open：调用封装好的 sys_open，将文件路径和标志位传递给系统，实际执行系统调用并返回文件描述符。

内核的处理

当 sys_open 被调用时，rCore 内核会处理来自用户态的系统调用，执行文件的查找、权限检查等操作，并最终返回文件描述符。文件描述符是一个整数，用于标识已打开的文件，它为后续的文件操作（例如读写）提供了句柄，简化了文件的操作流程。

OpenFlags 枚举

在 rCore 中，文件操作模式是通过 OpenFlags 枚举类型来定义的。这些标志位与传统操作系统中的文件操作模式类似：

#![allow(unused)]
fn main() {
bitflags! {
    pub struct OpenFlags: u32 {
        const RDONLY = 0;
        const WRONLY = 1 << 0;
        const RDWR = 1 << 1;
        const CREATE = 1 << 9;
        const TRUNC = 1 << 10;
    }
}
}

• RDONLY：只读模式。
• WRONLY：只写模式。
• RDWR：读写模式。
• CREATE：如果文件不存在，则创建该文件。
• TRUNC：如果文件存在，打开时清空文件内容。

2. write 系统调用

在 rCore 中，write 系统调用的实现与传统的 xv6 逻辑类似。它负责将数据从用户空间缓冲区写入到指定的文件中。在 Rust 中，由于其所有权模型和安全检查机制，这一过程变得更加复杂和安全。

#![allow(unused)]
fn main() {
// user/src/file.rs
pub fn write(fd: usize, buf: &[u8]) -> isize {
    sys_write(fd, buf)
}

// user/src/syscall.rs
pub fn sys_write(fd: usize, buffer: &[u8]) -> isize {
    syscall(SYSCALL_WRITE, [fd, buffer.as_ptr() as usize, buffer.len()])
}

// os/src/syscall/fs.rs
pub fn sys_write(fd: usize, buf: *const u8, len: usize) -> isize {
    let token = current_user_token();
    let process = current_process();
    let inner = process.inner_exclusive_access();
    if fd >= inner.fd_table.len() {
        return -1;
    }
    if let Some(file) = &inner.fd_table[fd] {
        if !file.writable() {
            return -1;
        }
        let file = file.clone();
        // release current task TCB manually to avoid multi-borrow
        drop(inner);
        file.write(UserBuffer::new(translated_byte_buffer(token, buf, len))) as isize
    } else {
        -1
    }
}
}

当用户想要向一个已打开的文件写入数据时，会调用 write 系统调用，并传递以下参数：

• 文件描述符（fd），表示要写入的文件，由 open 返回。
• 数据缓冲区（buffer），这是一个字节数组，包含要写入的数据。
• 要写入的数据长度（len），指定需要写入的字节数。

在 rCore 中，用户态和内核态的 write 调用分别由 user/src/syscall.rs 和 os/src/syscall/fs.rs 中的代码实现。

用户态的 write 实现

#![allow(unused)]
fn main() {
// user/src/syscall.rs
pub fn sys_write(fd: usize, buffer: &[u8]) -> isize {
    syscall(SYSCALL_WRITE, [fd, buffer.as_ptr() as usize, buffer.len()])
}
}

• sys_write 函数：

  • fd: usize：文件描述符，表示已经打开的文件。
  • buffer: &[u8]：这是一个字节数组切片，表示要写入的数据缓冲区。
  • 返回值类型是 isize，用于指示系统调用的结果，成功时返回写入的字节数，失败时返回负数（通常为 -1）。

• syscall 函数：

  • syscall 是一个通用的系统调用接口，负责将系统调用号和参数传递给内核，并等待内核返回结果。这里传递的参数包括：
    • SYSCALL_WRITE：表示 write 系统调用的系统调用号。
    • [fd, buffer.as_ptr() as usize, buffer.len()]：参数列表，其中：
      • buffer.as_ptr()：获取缓冲区的指针，指向数据在内存中的起始地址。
      • buffer.len()：获取缓冲区的长度，即要写入的字节数。

用户态通过 sys_write 调用，向内核发送系统调用请求，请求内核将 buffer 中的数据写入到文件。

内核态的 write 实现

#![allow(unused)]
fn main() {
// os/src/syscall/fs.rs
pub fn sys_write(fd: usize, buf: *const u8, len: usize) -> isize {
    let token = current_user_token();
    let process = current_process();
    let inner = process.inner_exclusive_access();
    if fd >= inner.fd_table.len() {
        return -1;
    }
    if let Some(file) = &inner.fd_table[fd] {
        if !file.writable() {
            return -1;
        }
        let file = file.clone();
        // release current task TCB manually to avoid multi-borrow
        drop(inner);
        file.write(UserBuffer::new(translated_byte_buffer(token, buf, len))) as isize
    } else {
        -1
    }
}
}

用户态调用接口

#![allow(unused)]
fn main() {
// user/src/file.rs
pub fn write(fd: usize, buf: &[u8]) -> isize {
    sys_write(fd, buf)
}
}

这个函数封装了对 sys_write 的调用，进一步简化了用户程序的使用接口。用户只需传递文件描述符和缓冲区，调用 write 函数即可完成数据写入操作。

内核态与用户态和系统调用

在操作系统中，内核态 和 用户态 是两种运行模式。它们提供了不同的权限级别，来保障系统安全性和稳定性。在讨论 系统调用 时，用户态和内核态有各自的作用和层次，这两者的协同工作是系统正常运行的基础。

内核态和用户态

• 用户态（User Mode）：运行普通应用程序的模式，权限有限，不能直接访问硬件或执行某些敏感操作（如 I/O 操作、内存管理等）。所有与硬件、资源管理相关的操作都必须通过系统调用请求内核来执行。
• 内核态（Kernel Mode）：运行操作系统内核和核心服务的模式，拥有最高权限，可以直接访问硬件资源，管理系统资源并执行重要的低级操作。系统调用会从用户态切换到内核态，让内核代替应用程序完成这些操作。

系统调用的概念

系统调用（System Call）是用户态程序与内核通信的机制。用户态程序需要通过系统调用来请求内核执行某些操作，例如文件读写、内存分配、进程管理等。

在用户态，系统调用看起来像是普通函数调用，但实际上，系统调用会触发 特权指令，将程序从用户态切换到内核态，内核负责处理请求后返回结果。

用户态和内核态在系统调用中的视角与作用

系统调用在不同的层次中有不同的表现，从用户态到内核态，每个层次都有其特定的工作。我们用一个 文件写操作（write 系统调用） 为例，展示其在不同层次的实现和视角。

(1) 用户态的视角：系统调用封装

在用户态，开发者看不到内核的细节，只能调用高层次的系统调用接口。以 rCore 用户态的 write 系统调用为例：

#![allow(unused)]
fn main() {
// 用户态：user/src/syscall.rs
pub fn sys_write(fd: usize, buffer: &[u8]) -> isize {
    syscall(SYSCALL_WRITE, [fd, buffer.as_ptr() as usize, buffer.len()])
}
}

用户态执行过程：

1. 封装系统调用：sys_write 是一个封装好的系统调用函数。用户态程序调用 sys_write，传递文件描述符 fd 和写入数据 buffer。
2. 参数准备：将参数打包成标准的形式（如将缓冲区指针转换为整数，准备文件描述符和长度）。
3. 发起系统调用：syscall(SYSCALL_WRITE, ...) 触发系统调用，通过硬件机制（如中断或陷入指令）将程序从用户态切换到内核态，并将请求传递给内核。

(2) 内核态的视角：处理系统调用

在内核态，操作系统接收到系统调用请求后，会处理这些用户态程序无法完成的任务。在 rCore 中，write 系统调用在内核的实现如下：

#![allow(unused)]
fn main() {
// 内核态：os/src/syscall/fs.rs
pub fn sys_write(fd: usize, buf: *const u8, len: usize) -> isize {
    let token = current_user_token();
    let process = current_process();
    let inner = process.inner_exclusive_access();
    
    // 检查文件描述符是否有效
    if fd >= inner.fd_table.len() {
        return -1;
    }

    // 查找文件并判断是否可写
    if let Some(file) = &inner.fd_table[fd] {
        if !file.writable() {
            return -1;
        }
        let file = file.clone();
        
        // 释放锁以防止重复借用
        drop(inner);
        
        // 将用户态缓冲区中的数据写入文件
        file.write(UserBuffer::new(translated_byte_buffer(token, buf, len))) as isize
    } else {
        -1
    }
}
}

内核态执行过程：

1. 参数接收：内核接收到用户态传递的参数，例如文件描述符 fd 和数据缓冲区指针 buf。
2. 用户态到内核态的缓冲区转换：由于用户态和内核态处于不同的地址空间，内核需要通过 translated_byte_buffer 函数将用户态缓冲区地址转换为内核态可访问的地址。
3. 权限检查：内核检查文件描述符是否有效，并确保该文件具有写权限。如果检查失败，则返回错误码。
4. 实际操作：内核调用内部的文件写入函数，将数据写入到对应的文件系统或设备中。
5. 返回结果：操作完成后，内核返回写入的字节数或错误码，并切换回用户态。

(3) 硬件的视角：用户态到内核态的切换

用户态程序通过系统调用进入内核态的过程涉及硬件机制：

1. 触发系统调用：系统调用通常是通过一条特殊的指令触发的，例如 syscall（在 x86-64 架构上）或 ecall（在 RISC-V 上）。这条指令会产生一个陷入（trap）或中断，导致处理器从用户态切换到内核态。

2. 进入内核态：处理器根据陷入向量跳转到内核的系统调用处理函数。陷入后，处理器会切换到内核态运行，并保护当前的用户态上下文。

   在 RISC-V 架构中，处理系统调用或异常的机制使用 陷入向量。关键寄存器：

   • stvec（Supervisor Trap Vector Base Address Register）：用于存储系统调用或异常处理函数的基地址。当发生系统调用或异常时，处理器会根据 stvec 的值跳转到对应的地址执行陷入处理函数。
   • 参见 lzzs xv6 notebook: usertrap

3. 保存上下文：内核会保存当前的用户态寄存器状态，以便在系统调用结束后能恢复用户态程序的执行。

系统调用流程总结

从系统调用的全过程来看，用户态和内核态的工作是密切相关的。用户态和内核态的系统调用处理过程可以分为几个关键步骤：

1. 用户态：

   • 发起系统调用，提供需要的参数（如文件描述符、缓冲区、数据长度等）。
   • 用户态程序并不知道内核的具体实现细节，它只关心系统调用的接口和结果。

2. 内核态：

   • 接收并处理系统调用，进行一系列操作，如权限检查、资源管理、硬件访问等。
   • 内核负责实际的操作，如与文件系统交互、与设备交互等。
   • 返回处理结果（如写入的字节数或错误码）并切换回用户态。

3. 硬件层：

   • 实现用户态与内核态的隔离，通过硬件机制确保用户态程序不能直接访问内核权限级别的资源。
   • 提供特权指令或陷入机制，允许用户态程序通过系统调用进入内核。

示例流程：文件写操作的系统调用

举例来说，用户态程序调用 write(fd, buffer) 的全过程如下：

1. 用户态：

   • 程序调用 sys_write(fd, buffer)，封装参数并通过 syscall函数使用 **ecall**指令触发系统调用。

2. 陷入内核：

   • ecall触发处理器切换到内核态，内核接管执行。

3. 内核态：

   • 内核的系统调用处理函数 sys_write(fd, buf, len) 接收参数。
   • 内核检查文件描述符的有效性、权限，确保写入操作合法。
   • 内核将数据从用户态缓冲区拷贝到内核缓冲区（必要时进行地址转换）。
   • 内核调用文件系统接口，将数据写入文件。
   • 完成写入操作后，返回结果（如写入的字节数），并切换回用户态。

4. 用户态继续执行：

   • 系统调用结束，程序继续执行，处理返回的结果。

总结

• 用户态 的视角：系统调用像普通函数一样，但其实底层涉及内核操作。
• 内核态 的视角：接收用户的系统调用请求，进行底层的资源管理和硬件交互操作。
• 硬件层 提供用户态和内核态的隔离机制，并通过陷入机制实现状态切换。

这层次化的设计保证了系统的安全性和稳定性，同时也为程序提供了强大的操作能力。

系统调用与syscall() 函数

系统调用（System Call）是操作系统提供给用户态程序与内核进行交互的一种机制。用户态程序无法直接访问硬件资源或者执行某些敏感的操作（如进程管理、文件操作等），因此需要通过系统调用向内核发出请求，执行这些操作。在用户态程序中，系统调用的接口通常封装成类似函数的调用形式，但其本质是通过硬件机制将执行权限从用户态切换到内核态。

在 rCore 操作系统中，系统调用通过 syscall() 函数来封装，这个函数根据不同的系统调用 ID 和参数，执行相应的操作。

syscall() 函数

#![allow(unused)]
fn main() {
// user/src/syscall.rs
fn syscall(id: usize, args: [usize; 3]) -> isize {
    let mut ret: isize;
    unsafe {
        core::arch::asm!(
            "ecall",                              // 触发系统调用
            inlateout("x10") args[0] => ret,      // 参数 1 传递给 x10 寄存器，返回值也通过 x10 返回
            in("x11") args[1],                    // 参数 2 传递给 x11
            in("x12") args[2],                    // 参数 3 传递给 x12
            in("x17") id                          // 系统调用号传递给 x17
        );
    }
    ret
}
}

syscall() 是系统调用的核心，它封装了系统调用的执行流程。这个函数的执行步骤如下：

1. 传递系统调用号：系统调用号（id）被传递给寄存器 x17，用于告诉内核应该执行哪种系统调用。

2. 传递参数：系统调用的三个参数存储在 x10, x11, x12 寄存器中，这些寄存器会传递到内核中的系统调用处理程序。

3. 触发系统调用：使用 ecall 指令触发系统调用，中断当前的用户态执行，进入内核态。

4. 返回结果：系统调用的返回值通过 x10 寄存器返回给用户程序，存储在 ret 变量中。

   RISC-V 处理器有 32 个通用寄存器（x0 到 x31），其中某些寄存器被预先规定用于特定的目的，比如存储函数参数、返回值、临时值和保存调用者的上下文等。

   在 RISC-V 架构中，函数调用（包括系统调用）的参数传递和返回值处理是由 RISC-V ABI 和指令集规范定义的。具体来说，不论是普通函数还是系统调用，参数和返回值都通过指定的寄存器进行传递。这些寄存器的使用规则在 RISC-V Calling Convention 中有明确的定义。

典型系统调用的实现

1. sys_open() 系统调用

sys_open() 是用于打开文件的系统调用。在用户态，sys_open() 封装了文件打开操作，它将文件路径和打开模式传递给内核，通过 syscall() 来执行。

#![allow(unused)]
fn main() {
pub fn sys_open(path: &str, flags: u32) -> isize {
    syscall(SYSCALL_OPEN, [path.as_ptr() as usize, flags as usize, 0])
}
}

• 系统调用号：SYSCALL_OPEN 指定了这是一个文件打开操作。
• 参数：
  • path.as_ptr() as usize：文件路径的指针地址被传递给内核。
  • flags as usize：指定文件的打开模式（如只读、只写等）。

内核处理文件打开请求后，返回一个文件描述符，该描述符用于后续的文件操作（如读写）。

2. sys_write() 系统调用

sys_write() 是用于向文件或标准输出写入数据的系统调用。该系统调用将文件描述符、写入的缓冲区和缓冲区的长度作为参数传递给内核。

#![allow(unused)]
fn main() {
pub fn sys_write(fd: usize, buffer: &[u8]) -> isize {
    syscall(SYSCALL_WRITE, [fd, buffer.as_ptr() as usize, buffer.len()])
}
}

• 系统调用号：SYSCALL_WRITE 指定了这是一个写操作。
• 参数：
  • fd：文件描述符，指定要写入的文件或输出流。
  • buffer.as_ptr() as usize：数据缓冲区的指针。
  • buffer.len()：要写入的数据长度。

内核会根据文件描述符，将缓冲区中的数据写入到指定的文件或设备中。

其他系统调用

sys_open 和 sys_write 的系统调用模式适用于大多数其他系统调用，流程基本相同：

1. 将系统调用号和参数传递给 syscall() 函数。
2. 通过 ecall 触发内核执行操作。
3. 获取结果并返回给用户态程序。

类似的系统调用有：

• sys_read()：读取文件内容。
• sys_close()：关闭打开的文件描述符。
• sys_fork()：创建一个新的进程。
• sys_exit()：退出当前进程。

每个系统调用根据不同的操作会传递不同的参数，但它们的工作机制都是类似的，通过 syscall() 函数向内核发起请求，执行系统级的操作。更多 rCore 系统调用参见user/src/syscall.rs

总的来说，系统调用是用户态程序与内核进行交互的桥梁。在 rCore 中，syscall() 函数封装了系统调用的执行流程，用户态程序通过调用相应的系统调用函数（如 sys_open、sys_write 等），间接调用内核提供的服务。系统调用的机制保证了用户态和内核态的隔离，确保了系统的安全性和稳定性。

接下来的章节将开始深入探讨如何通过这些系统调用实现更复杂的系统操作，如进程管理、文件操作以及设备交互。

hello_world.rs

在操作系统开发的过程中，用户态程序是与内核交互的关键桥梁。一个简单的用户态程序可以通过调用系统调用，与操作系统内核进行通讯、执行文件操作、管理进程和输入输出等任务。在本章中，我们将以一个经典的 "Hello, World!" 程序作为切入点，探讨用户态程序的结构与实现方式，并逐步分析它如何通过系统调用与内核进行交互。

这个 hello_world.rs 程序展示了一个用户态应用如何在不依赖标准库的环境下，使用 Rust 的基本功能输出到控制台。通过深入分析这个简单的程序，我们将揭示从 println! 宏到底层的输出实现，了解 用户态 和 内核态 的交互原理。

接下来，我们将首先讲解 hello_world.rs 程序的基本结构，然后逐步深入分析控制台输出的实现方式，并探索 rCore 中如何使用 Rust 的特性来实现安全、高效的系统调用机制。

"Hello, World!"

// user/src/bin/hello_world.rs

#![no_std]
#![no_main]

#[macro_use]
extern crate user_lib;

#[no_mangle]
pub fn main() -> i32 {
    println!("Hello world from user mode program!");
    0
}

// user/src/console.rs
impl Write for Stdout {
    fn write_str(&mut self, s: &str) -> fmt::Result {
        write(STDOUT, s.as_bytes());
        Ok(())
    }
}

// user/src/console.rs
use core::fmt::{self, Write};

const STDIN: usize = 0;
const STDOUT: usize = 1;

use super::{read, write};

struct Stdout;

impl Write for Stdout {
    fn write_str(&mut self, s: &str) -> fmt::Result {
        write(STDOUT, s.as_bytes());
        Ok(())
    }
}

pub fn print(args: fmt::Arguments) {
    Stdout.write_fmt(args).unwrap();
}

#[macro_export]
macro_rules! print {
    ($fmt: literal $(, $($arg: tt)+)?) => {
        $crate::console::print(format_args!($fmt $(, $($arg)+)?));
    }
}

#[macro_export]
macro_rules! println {
    ($fmt: literal $(, $($arg: tt)+)?) => {
        $crate::console::print(format_args!(concat!($fmt, "\n") $(, $($arg)+)?));
    }
}

pub fn getchar() -> u8 {
    let mut c = [0u8; 1];
    read(STDIN, &mut c);
    c[0]
}

用户程序：hello_world.rs

#![no_std]
#![no_main]

#[macro_use]
extern crate user_lib;

#[no_mangle]
pub fn main() -> i32 {
    println!("Hello world from user mode program!");
    0
}

• #![no_std]：

  • 这个指令告诉编译器不使用标准库 (std)。在 rCore 中，由于这是一个操作系统运行在裸机上，没有完整的标准库支持，因此需要使用 no_std 环境。
  • 取而代之的是 core 库，它提供了语言本身的基础功能（例如基础类型、内存操作等），但没有诸如文件系统或 I/O 等高级功能。

• #![no_main]：

  • 由于操作系统的用户程序不需要 std 库中的标准 main 函数签名，使用 #![no_main] 来禁用标准的入口点。相反，用户自己定义一个 main 函数作为入口。

• #[macro_use]：

  • 这指令引入了 user_lib 中的宏定义，允许在当前文件中使用该库定义的宏（如 println!）。

• extern crate user_lib;：

  • 明确导入外部库 user_lib，这是 rCore 的用户态库，提供了与系统交互的基础设施，包括系统调用、打印等操作。

• #[no_mangle]：

  • 这是一个属性，防止编译器对函数名进行名称混淆（mangling）。main 函数作为入口函数必须保持原始名称，以便系统能正确调用。

• println! 宏：

  • 这是用户态打印宏，用于打印 "Hello world from user mode program!"。
  • println! 是宏，它将字符串打印到标准输出 (stdout)。

控制台输入输出：console.rs

#![allow(unused)]
fn main() {
use core::fmt::{self, Write};

const STDIN: usize = 0;
const STDOUT: usize = 1;

use super::{read, write};

struct Stdout;
...
}

• core::fmt::Write：

  • Write 是一个 core::fmt 模块中的 trait，用于处理格式化输出。通过实现 Write trait，可以自定义如何将数据写入输出（例如标准输出）。

• STDIN 和 STDOUT：

  • 这是两个常量，STDIN 和 STDOUT 分别对应标准输入和标准输出的文件描述符编号。它们用于系统调用中的读写操作。

• struct Stdout：

  • Stdout 是一个空结构体，用于表示标准输出设备。

实现 Write trait

#![allow(unused)]
fn main() {
impl Write for Stdout {
    fn write_str(&mut self, s: &str) -> fmt::Result {
        write(STDOUT, s.as_bytes());
        Ok(())
    }
}
}

• impl Write for Stdout：

  • 这里实现了 Write trait 的 write_str 方法，用于将字符串输出到标准输出。
  • 通过实现 Write trait，Stdout 结构体可以用于格式化输出，类似于 C 语言中的 printf。

• write_str 方法：

  • 接收一个字符串 s: &str，将其转化为字节数组（as_bytes()）后，通过 write(STDOUT, s.as_bytes()) 系统调用将数据写入标准输出。
  • fmt::Result 是返回类型，表示格式化操作是否成功。在这里，总是返回 Ok(()) 表示成功。

打印函数与宏：print! 和 println!

#![allow(unused)]
fn main() {
pub fn print(args: fmt::Arguments) {
    Stdout.write_fmt(args).unwrap();
}

#[macro_export]
macro_rules! print {
    ($fmt: literal $(, $($arg: tt)+)?) => {
        $crate::console::print(format_args!($fmt $(, $($arg)+)?));
    }
}

#[macro_export]
macro_rules! println {
    ($fmt: literal $(, $($arg: tt)+)?) => {
        $crate::console::print(format_args!(concat!($fmt, "\n") $(, $($arg)+)?));
    }
}
}

• print(args: fmt::Arguments)：

  • 这是一个接收 fmt::Arguments 的函数，fmt::Arguments 是用于格式化输出的数据结构，通常通过 format_args! 宏生成。函数调用 Stdout.write_fmt(args) 执行格式化输出，将数据写入 Stdout。

• print! 和 println! 宏：

  • 这两个宏分别对应打印和带换行符的打印（类似于 printf 和 puts）。
  • println! 使用了 concat! 宏将字符串内容与换行符 \n 拼接，确保打印后自动换行。
  • format_args!宏会生成 fmt::Arguments 类型的对象，用于格式化输出。它将字符串和任何附加的参数转换成一种可以用于输出的可变参数类型，支持 Write trait 的实现。
  • 这些宏的作用是简化格式化输出，用户可以像在常规环境中那样使用 print! 和 println!。

宏展开示例

#![allow(unused)]
fn main() {
println!("Hello, world!");
}

展开后：

#![allow(unused)]
fn main() {
$crate::console::print(format_args!(concat!("Hello, world!", "\n")));
}

这会将 "Hello, world!\n" 作为参数传递给 console::print 函数。

系统调用的封装

在用户态程序中，write 和 read 函数都是系统调用，它们负责与内核通信，将数据写入或从标准输入读取数据。在这里，通过调用这些封装的系统调用函数实现输入输出功能。

write 系统调用回顾

write() 函数定义在用户态库中，负责将数据通过系统调用发送到内核：

#![allow(unused)]
fn main() {
pub fn write(fd: usize, buf: &[u8]) -> isize {
    sys_write(fd, buf)
}
}

sys_write 封装了对内核的系统调用，实际上发起了将数据从用户态发送到内核态的请求：

#![allow(unused)]
fn main() {
pub fn sys_write(fd: usize, buffer: &[u8]) -> isize {
    syscall(SYSCALL_WRITE, [fd, buffer.as_ptr() as usize, buffer.len()])
}
}

当 sys_write 被调用时，操作系统的内核会处理这个系统调用，并将数据写入到对应的设备（在本例中是标准输出）。

简化的内核流程如下：

1. 内核接收系统调用 SYSCALL_WRITE 及其参数。
2. 内核检查文件描述符 fd 是否有效（例如 1 对应 STDOUT）。
3. 内核将用户传入的缓冲区地址和长度转换为内核可访问的地址空间。
4. 内核将字节数据写入标准输出设备（例如屏幕、终端等）。
5. 如果写入成功，内核返回写入的字节数；如果失败，返回负数表示错误。

流程总结

1. 用户调用 println!("Hello, world!")，该宏展开后生成对 print() 函数的调用，并将格式化的 fmt::Arguments 传递给 print。
2. print 函数调用 Stdout.write_fmt(args)，将格式化的数据传递给标准输出。
3. Stdout.write_fmt(args) 调用 write_str()，将字符串转换为字节数组并通过 write(STDOUT, s.as_bytes()) 系统调用发起写请求。
4. write(fd, buf) 通过 sys_write(fd, buf) 将数据发送给内核，内核将数据写入标准输出设备（如终端、屏幕等）。
5. 数据成功输出后，内核返回写入的字节数，用户态函数处理该返回值。

整个流程的核心在于：

• println! 宏展开 ->
• print 调用 ->
• Stdout.write_fmt() 处理格式化输出 ->
• sys_write() 系统调用 ->
• 内核处理标准输出。

通过这种方式，rCore 用户态程序实现了将数据从用户态打印到标准输出的完整流程。

Write trait

Stdout 结构体实现了 Write trait，并且 write_fmt() 依赖 write_str() 来实际执行写操作。

write_str

#![allow(unused)]
fn main() {
impl Write for Stdout {
    fn write_str(&mut self, s: &str) -> fmt::Result {
        write(STDOUT, s.as_bytes());
        Ok(())
    }
}
}

• Write trait：Write trait 定义了如何将格式化后的数据写入某种输出设备。write_str() 是 Write trait 的方法之一，专门用于写入字符串。
• write_str(&mut self, s: &str)：
  • 这个函数接收一个不可变的字符串切片 &str，然后将字符串内容转换为字节数组 s.as_bytes()，再通过 write 函数将字节数组写入标准输出。
  • STDOUT 是标准输出文件描述符，通常为 1。调用 write(STDOUT, s.as_bytes())，这实际发起了对系统调用 write 的请求，将数据发送到标准输出设备。

Required Methods: write_str, Provided Methods: write_fmt

在 Rust 中，write_fmt 和 write_str 是通过实现 Write trait 关联起来的。write_fmt 是一个定义在 core::fmt::Write trait 中的高层次方法，用于格式化输出，而 write_str 是 Write trait 的一个低层方法，专门用来处理字符串的写入。

要了解它们之间的关系，我们需要理解 core::fmt::Write trait 是如何工作的。让我们详细说明这两个函数是如何通过 Write trait 关联起来的。

Rust 的官方文档会列出所有方法，并在描述中明确说明哪些是必须实现(Required Methods)的，哪些是有默认实现(Provided Methods)的。例如，搜索 core::fmt::Write ，

查看它的说明部分。

#![allow(unused)]
fn main() {
pub trait Write {
    // Required method
    fn write_str(&mut self, s: &str) -> Result;

    // Provided methods
    fn write_char(&mut self, c: char) -> Result { ... }
    fn write_fmt(&mut self, args: Arguments<'_>) -> Result { ... }
}
}

文档明确区分了 "Required method"（必需实现的方法）和 "Provided methods"（有默认实现的方法）。在 Rust 的文档中，这种方式非常有用，帮助我们快速了解哪些方法是必须要实现的，哪些可以依赖于默认实现。

这里隐藏了默认实现的代码，你可以点击右侧的 source 按钮查看源代码。

#![allow(unused)]
fn main() {
pub trait Write {
    ...
    fn write_str(&mut self, s: &str) -> Result;

    ...
    fn write_char(&mut self, c: char) -> Result {
        self.write_str(c.encode_utf8(&mut [0; 4]))
    }

    ...
    fn write_fmt(mut self: &mut Self, args: Arguments<'_>) -> Result {
        write(&mut self, args)
    }
}
}

这是 Write trait 的一部分，它定义了在 Rust 中处理格式化输出的行为。我们会逐步分析这个代码片段中每个方法的作用和工作原理。

write_str 方法

#![allow(unused)]
fn main() {
fn write_str(&mut self, s: &str) -> Result;
}

• write_str 是 Write trait 中唯一的必须实现的方法。它的任务是将传入的字符串 s 写入输出设备（如文件、标准输出、缓冲区等）。
• &mut self：表示该方法会对实现 Write trait 的目标进行可变引用。目标可能是一个缓冲区或其他输出流。
• s: &str：这是传入的字符串，它是一个不可变的字符串切片（&str）。
• Result：返回值是一个标准的 Result 类型，通常用于表示操作是否成功。Ok(()) 表示成功，Err 表示发生错误。

任何实现了 Write trait 的类型，都需要提供 write_str 的具体实现，它是输出行为的基础。

write_char 方法

#![allow(unused)]
fn main() {
fn write_char(&mut self, c: char) -> Result {
    self.write_str(c.encode_utf8(&mut [0; 4]))
}
}

• write_char 是 Write trait 的一个默认实现，它的任务是将单个字符 c 写入目标。
• 字符编码：由于在计算机系统中，字符（char）通常需要编码为字节序列才能被写入，因此 write_char 方法使用 c.encode_utf8() 将字符 c 编码为 UTF-8 字符串。
  • c.encode_utf8(&mut [0; 4])：这是将字符 c 编码为 UTF-8 的方法。由于 UTF-8 编码一个字符最多需要 4 个字节，因此这里使用一个长度为 4 的数组作为缓冲区，来存储编码后的字节。
• self.write_str：将编码后的字符串通过 write_str 方法写入输出目标。
• 默认实现：如果类型没有显式实现 write_char，它会使用这个默认的实现。

write_fmt 方法

#![allow(unused)]
fn main() {
fn write_fmt(mut self: &mut Self, args: Arguments<'_>) -> Result {
    write(&mut self, args)
}
}

• write_fmt 是 Write trait 的另一个默认实现，用于处理格式化输出。它接受一个 fmt::Arguments 类型的参数 args，这是由 format_args! 宏生成的格式化数据。
• Arguments<'_>：这是一个专门用于格式化输出的类型，封装了格式化字符串和格式化参数（如 println! 或 format!）。
• write_fmt 的工作：
  • write 函数：实际完成输出工作的函数是 fmt::write，它会将 args 中的格式化内容解析并通过 self.write_str 写入输出目标。
  • mut self: &mut Self：表示 write_fmt 方法会对目标进行可变引用。

write_fmt 提供了一个高层次的接口，用于处理复杂的格式化输出，如 println! 或 format!。如果类型实现了 write_str，write_fmt 可以通过这个默认实现直接使用。

write 函数: fmt::write

#![allow(unused)]
fn main() {
pub fn write(output: &mut dyn Write, args: Arguments<'_>) -> Result {
    let mut formatter = Formatter::new(output);
    let mut idx = 0;

    match args.fmt {
        None => {
            // 我们可以对所有参数使用默认格式设置参数。
            for (i, arg) in args.args.iter().enumerate() {
                // SAFETY: args.args 和 args.pieces 来自同一个参数，保证索引总是在限定范围内。
                //
                let piece = unsafe { args.pieces.get_unchecked(i) };
                if !piece.is_empty() {
                    formatter.buf.write_str(*piece)?;
                }
                arg.fmt(&mut formatter)?;
                idx += 1;
            }
        }
        Some(fmt) => {
            // 每个规范都有一个对应的参数，该参数后有一个字符串。
            //
            for (i, arg) in fmt.iter().enumerate() {
                // SAFETY: fmt 和 args.pieces 来自同一个 参数，保证索引总是在限定范围内。
                //
                let piece = unsafe { args.pieces.get_unchecked(i) };
                if !piece.is_empty() {
                    formatter.buf.write_str(*piece)?;
                }
                // SAFETY: arg 和 args.args 来自相同的参数，从而确保索引始终在范围之内。
                //
                unsafe { run(&mut formatter, arg, args.args) }?;
                idx += 1;
            }
        }
    }

    // 只能剩下一个尾随的字符串切片。
    if let Some(piece) = args.pieces.get(idx) {
        formatter.buf.write_str(*piece)?;
    }

    Ok(())
}
}

刚才的源码中也包含write 函数，你也可以在 Module core::fmt 看到 Functions 中包含 write，即fmt::write。

这个 write 函数是 Rust 中 core::fmt 模块的重要部分，它用于将格式化的输出写入到实现了 Write trait 的目标。该函数是格式化输出（如 println! 或 format!）的底层实现之一，依赖于 Arguments 结构体，Arguments 由宏如 format_args! 预编译生成，包含了格式化输出所需的信息。

#![allow(unused)]
fn main() {
let mut formatter = Formatter::new(output);
}

#![allow(unused)]
fn main() {
Hello {}!
}

#![allow(unused)]
fn main() {
if let Some(piece) = args.pieces.get(idx) {
    formatter.buf.write_str(*piece)?;
}
}

#![allow(unused)]
fn main() {
use std::fmt::Write;

let mut output = String::new();
write!(&mut output, "Hello {}!", "world")
    .expect("Error occurred while trying to write in String");
assert_eq!(output, "Hello world!");
}

示例代码解读

文档中的示例展示了如何使用 fmt::write 将格式化内容写入到 String 中：

#![allow(unused)]
fn main() {
use std::fmt;

let mut output = String::new();
fmt::write(&mut output, format_args!("Hello {}!", "world"))
    .expect("Error occurred while trying to write in String");
assert_eq!(output, "Hello world!");
}

工作流程

1. format_args! 宏：
   • 宏 format_args!("Hello {}!", "world") 会生成一个 Arguments 结构体，包含 "Hello " 和 "!" 作为静态字符串片段，以及 "world" 作为参数。
2. write_fmt
   • 如果调用 write_fmt（如通过 println! 或 write! 宏间接调用）实际调用的是 fmt::write 函数。
   • fmt::write 遍历 fmt::Arguments，其中的格式化片段最终都通过调用 write_str 写入输出流。
3. fmt::write 函数：
   • fmt::write(&mut output, format_args!(...)) 将格式化内容写入 output，其中 output 是一个 String。这个 String 实现了 Write trait，所以可以作为输出流。
4. 最终输出：
   • 最终，output 中包含 "Hello world!"，这个值被断言验证。

println! 宏

标准库中的 println! 宏

在使用 标准库（即没有使用 #![no_std] 的项目）时，println! 宏是由标准库自动提供的。它依赖于标准库中已经实现的输入/输出系统和格式化输出机制。

在标准环境下：

• println! 是由 std::fmt 模块提供的宏，用户可以直接使用它来向标准输出打印格式化的文本。
• println! 会自动将输出定向到标准输出（如终端），并且它使用了标准库的 Write trait 和相关的 I/O 设施。

fn main() {
    println!("Hello, world!");  // 使用标准库中的 println! 宏
}

这个例子中，println! 宏自动可用，因为 标准库 提供了它的实现。

no_std 环境下的 println! 宏

当你在一个 no_std 项目中工作时，标准库是不可用的，因为它依赖于高级的操作系统功能（如文件系统、标准 I/O 等），这些功能在裸机或嵌入式开发中是不可用的。

• 在 no_std 环境中，标准库中的 println! 宏不可用，因此如果需要类似的功能，你必须自己实现。
• 在 no_std 环境中，通常需要自己定义如何处理 I/O，比如打印到串口、内存映射的 I/O 设备，或者像 rCore 这样的操作系统中的设备驱动程序。
• 为了实现类似的 println! 功能，你需要手动实现输入输出的逻辑（如 write 函数）以及相应的 宏 来实现格式化打印功能。

在本节开始的代码中，println! 宏就是手动实现的，适配了相应的输入输出系统，而不是使用标准库中的版本。

对比：标准库 vs no_std 环境下的 println!

为什么 no_std 需要自己实现 println!？

no_std 环境下没有标准库，意味着：

• 没有标准的 I/O 库，因此没有默认的标准输出设备。
• 没有标准库中的宏，如 println!，所以需要自己定义类似的功能来适应具体的运行环境。

在 rCore 代码中手动实现的 println! 宏通过调用自定义的 console::print 函数来实现输出功能。这是因为在 no_std 环境下，我们不能依赖标准库的输入输出设施。

#![allow(unused)]
fn main() {
#[macro_export]
macro_rules! println {
    ($fmt: literal $(, $($arg: tt)+)?) => {
        $crate::console::print(format_args!(concat!($fmt, "\n") $(, $($arg)+)?));
    }
}
}

这个自定义的 println! 宏定义了如何将格式化字符串打印到设备上，而不依赖标准库。

从 hello_world.rs 到sys_write

让我们从头到尾回顾一下整个流程，从 hello_world.rs 程序开始，一直到系统调用触发内核处理输出的过程。这一过程涵盖了 Rust 宏的展开、Write trait 的实现、格式化字符串处理、系统调用 以及 内核态与用户态的切换。

1. 用户态程序 hello_world.rs

#![no_std]
#![no_main]

#[macro_use]
extern crate user_lib;

#[no_mangle]
pub fn main() -> i32 {
    println!("Hello world from user mode program!");
    0
}

这个简单的用户态程序使用 println! 宏来打印 "Hello world from user mode program!"。由于这是一个 no_std 项目，它不依赖标准库，而是使用 rCore 定义的自定义宏和库。

关键点

• #![no_std]：表示禁用了标准库，不能使用如 println! 等标准库宏，必须自己实现。
• #![no_main]：没有使用标准的 main 函数，而是自定义程序入口。
• println!：使用 println! 宏进行格式化字符串输出。

2. println! 宏展开

println! 是在 user_lib 中自定义的一个宏，定义在 console.rs 文件中：

#![allow(unused)]
fn main() {
#[macro_export]
macro_rules! println {
    ($fmt: literal $(, $($arg: tt)+)?) => {
        $crate::console::print(format_args!(concat!($fmt, "\n") $(, $($arg)+)?));
    }
}
}

宏展开解释

• println! 宏接收一个格式化字符串 $fmt，并将它和换行符 \n 连接在一起，形成 "Hello world from user mode program!\n"。
• format_args!：将字符串和任何格式化参数打包成 fmt::Arguments，这是 Rust 标准格式化输出的基础。
• $crate::console::print()：最终宏会调用 console::print 函数，将生成的 fmt::Arguments 传递给它。

3. print() 函数

println! 宏展开后，调用了 console.rs 中的 print 函数：

#![allow(unused)]
fn main() {
pub fn print(args: fmt::Arguments) {
    Stdout.write_fmt(args).unwrap();
}
}

• print() 接收格式化后的 fmt::Arguments 参数，并调用 Stdout 结构体的 write_fmt 方法。
• write_fmt 是 Write trait 提供的默认实现，用于处理格式化输出，它依赖于 write_str 来完成输出。

4. Write trait 的实现

Stdout 结构体实现了 Write trait 的核心方法 write_str，这允许 Stdout 处理字符串并输出。

#![allow(unused)]
fn main() {
impl Write for Stdout {
    fn write_str(&mut self, s: &str) -> fmt::Result {
        write(STDOUT, s.as_bytes());  // 调用底层的 write 函数，将字符串转换为字节并写入标准输出
        Ok(())
    }
}
}

Write trait 工作原理

• write_str：将传入的字符串 s 转换为字节数组（as_bytes），并调用底层的 write 函数，将这些字节传递给输出设备。
• write_fmt：通过 write_str 完成格式化数据的写入，它会逐步将格式化字符串中的每个部分（如 "Hello world" 和 \n）输出。

5. write 函数与系统调用

write 函数负责将字符串数据写入到标准输出设备（如屏幕或文件），它最终触发一个 系统调用（sys_write）：

#![allow(unused)]
fn main() {
pub fn write(fd: usize, buf: &[u8]) -> isize {
    sys_write(fd, buf)  // 通过系统调用将数据写入标准输出
}
}

• fd：文件描述符，表示要写入的输出设备（STDOUT 通常是 1）。
• buf：要写入的数据缓冲区，这里是字节数组形式的字符串。
• sys_write：执行实际的系统调用，将数据从用户态传递到内核态。

6. sys_write 系统调用

sys_write 是用户态程序与内核通信的方式，它通过系统调用号 SYSCALL_WRITE 来告知内核要执行写操作。

#![allow(unused)]
fn main() {
pub fn sys_write(fd: usize, buffer: &[u8]) -> isize {
    syscall(SYSCALL_WRITE, [fd, buffer.as_ptr() as usize, buffer.len()])
}
}

• syscall：这是系统调用的封装函数，它负责通过 ecall 指令将控制权从用户态切换到内核态，并传递必要的参数。

7. syscall 函数与 RISC-V ecall 指令

#![allow(unused)]
fn main() {
fn syscall(id: usize, args: [usize; 3]) -> isize {
    let mut ret: isize;
    unsafe {
        core::arch::asm!(
            "ecall",                              // 触发系统调用
            inlateout("x10") args[0] => ret,      // 参数 1 -> x10, 返回值从 x10 获取
            in("x11") args[1],                    // 参数 2 -> x11
            in("x12") args[2],                    // 参数 3 -> x12
            in("x17") id                          // 系统调用号 -> x17
        );
    }
    ret
}
}

• x10 到 x12：用于传递系统调用的参数（如文件描述符、缓冲区指针和长度）。
• x17：存储系统调用号，这里是 SYSCALL_WRITE，表示这是一个写操作。
• ecall：触发系统调用，将 CPU 从用户模式切换到内核模式，进入内核处理程序。

8. 内核态处理 sys_write 系统调用

在内核态，系统调用 sys_write 的处理函数位于 syscall/fs.rs 中：

#![allow(unused)]
fn main() {
pub fn sys_write(fd: usize, buf: *const u8, len: usize) -> isize {
    let token = current_user_token();
    let process = current_process();
    let inner = process.inner_exclusive_access();

    if fd >= inner.fd_table.len() {
        return -1;
    }

    if let Some(file) = &inner.fd_table[fd] {
        if !file.writable() {
            return -1;
        }
        let file = file.clone();
        drop(inner);
        file.write(UserBuffer::new(translated_byte_buffer(token, buf, len))) as isize
    } else {
        -1
    }
}
}

内核态处理流程

1. 参数解析：从用户态接收传递的参数（文件描述符 fd、缓冲区指针 buf、数据长度 len）。
2. 权限检查：检查文件描述符是否有效、文件是否可写。
3. 数据写入：将缓冲区中的数据通过内核的文件系统接口写入到对应的输出设备。
4. 返回结果：系统调用完成后，将写入的字节数返回到用户态。

9. 从内核返回用户态

系统调用执行完毕后，内核通过寄存器将返回值传回用户态。用户程序从 sys_write 函数中接收返回值，表示写操作成功写入的字节数。

全流程总结

1. hello_world.rs 程序调用 println! 宏，开始格式化输出。
2. println! 宏展开 后调用了 print() 函数，传递格式化后的字符串。
3. print() 函数通过 Stdout.write_fmt() 输出格式化数据，实际调用了 write_str() 方法处理字符串。
4. write() 函数 通过 sys_write 发起系统调用，将数据传递给内核。
5. syscall() 函数 使用 RISC-V 的 ecall 指令触发系统调用，切换到内核态。
6. 内核态的 sys_write 处理 将数据写入标准输出设备，并将结果返回给用户态。
7. 最终，用户程序完成了 "Hello world from user mode program!" 的输出。

这个全流程展示了从用户态程序中的格式化字符串输出到内核处理系统调用，再到最终完成输出的整个

0. GDB章节

GDB安装

安装 GDB 流程来自【笔记】rCore (RISC-V)：GDB 使用记录 - 2024/04/25 - 苦瓜小仔。

以下是对整个流程的详细描述和讲解：

1. 安装依赖项

首先，我们需要为编译 GDB 安装一些必要的依赖项。libncurses5-dev 是为终端用户界面 (TUI) 提供支持的库，其他依赖项包括 texinfo 和 libreadline-dev，它们用于支持命令行输入以及生成文档。

sudo apt-get install libncurses5-dev texinfo libreadline-dev

在这里，Python 和 Python 开发库（python-dev）并不严格要求是 Python 2，也可以是 Python 3。只要你的系统中有 Python 3，它可以正常编译和运行。

使用 Python 3 进行配置

由于 Python 2 逐步被淘汰，建议你使用 Python 3。请确保系统中已经安装了 Python 3，并且有对应的开发库 python3-dev。你可以通过以下命令安装这些包：

sudo apt-get install python3 python3-dev

2. 检查本地 Python 路径

在编译 GDB 时，需要确保 Python 的路径正确。你可以通过以下命令来检查 Python3 的路径：

which python3

也可以通过以下命令查看详细的 Python 路径信息，确认是否链接到 Python 3：

ll $(which python3)

例如，输出可能是：

/usr/bin/python3 -> python3.8

3. 下载最新的 GDB 源码

从清华大学的开源镜像站下载 GDB 源码。确保下载的是最新版本，比如 gdb-14.2.tar.xz：

wget https://mirrors.tuna.tsinghua.edu.cn/gnu/gdb/gdb-14.2.tar.xz

4. 解压源码文件

解压下载好的压缩文件。你可以使用标准的 tar 命令，或者使用其他工具（如 ouch）来解压文件。

tar -xvf gdb-14.2.tar.xz

或

ouch d gdb-14.2.tar.xz

解压后，源码文件将位于当前目录的 gdb-14.2 文件夹中。

5. 创建构建目录

进入 gdb-14.2 目录，并在该目录下创建一个新的目录来存放构建结果和生成的二进制文件：

cd gdb-14.2
mkdir build-riscv64

6. 配置编译参数

进入创建的构建目录 build-riscv64，并通过 configure 脚本配置编译参数。指定安装路径、Python 路径、目标架构（RISC-V），并启用 TUI（终端用户界面）支持：

cd build-riscv64

../configure --prefix=/root/qemu/gdb-14.2/build-riscv64 --with-python=/usr/bin/python3 --target=riscv64-unknown-elf --enable-tui=yes

• ../configure: configure在gdb-14.2目录。
• --prefix=/root/qemu/gdb-14.2/build-riscv64：指定安装路径。
• --with-python=/usr/bin/python3：指定 Python 路径。
• --target=riscv64-unknown-elf：指定目标平台（RISC-V 架构）。
• --enable-tui=yes：启用 TUI 支持。

在编译 GDB（GNU 调试器）时，configure 脚本可以使用多种选项来指定编译过程中的配置和行为。这些选项可以用于指定编译目标、启用或禁用某些功能、配置依赖项路径等。下面详细介绍一些常见的 configure 配置参数及其作用。

1. --prefix=PREFIX

• 作用: 指定安装的根目录。编译后的 GDB 文件会被安装到该目录中。

• 示例:

  --prefix=/usr/local/gdb
  

  这将会把 GDB 安装到 /usr/local/gdb，其中可执行文件会放在 bin/ 目录，库文件会放在 lib/ 目录等。

2. --target=TARGET

• 作用: 指定要调试的目标架构。这是交叉编译的情况下非常重要的选项，定义你希望调试的架构类型。

• 示例:

  --target=riscv64-unknown-elf
  

  这指定了要生成支持 RISC-V 架构的 GDB。

3. --with-python[=PYTHON]

• 作用: 启用 Python 支持并可选择性地指定 Python 解释器的路径。GDB 支持 Python 插件，因此 Python 支持对于扩展 GDB 功能非常重要。

• 默认: 如果没有提供路径，GDB 会自动查找系统中的 Python。

• 示例:

  --with-python=/usr/bin/python3
  

  如果你不指定路径，你可以使用：

  --with-python=yes
  

  这会让 configure 脚本自动找到可用的 Python 解释器。

4. --enable-tui

• 作用: 启用 TUI（Text User Interface，文本用户界面）模式，这使得 GDB 提供类似于 vi 和 emacs 的命令行界面。

• 示例:

  --enable-tui
  

  启用 TUI 模式后，GDB 会有分屏窗口用于显示源代码和寄存器内容等，非常适合调试时查看复杂的程序状态。

5. --disable-nls

• 作用: 禁用 NLS（Native Language Support，本地语言支持），即禁用国际化功能。如果你不需要在调试器中显示非英语的本地化内容，可以选择禁用此选项。

• 示例:

  --disable-nls
  

6. --with-gmp=DIR 和 --with-mpfr=DIR

• 作用: 指定 GMP 和 MPFR 的安装路径，GDB 需要这两个库来进行高精度数学计算。GMP 和 MPFR 是很多编译器和调试器的数学库依赖项。

• 示例:

  --with-gmp=/usr/local
  --with-mpfr=/usr/local
  

7. --disable-werror

• 作用: 在编译过程中，GDB 默认会将所有警告视为错误。启用这个选项可以避免警告被视为错误，从而使编译能够继续，即使出现了非致命性警告。

• 示例:

  --disable-werror
  

8. --enable-targets=TARGETS

• 作用: 启用对多个目标架构的支持。GDB 可以在一个实例中支持多个不同的架构，因此可以同时调试不同平台的程序。

• 示例:

  --enable-targets=all
  

  这将启用所有支持的目标架构，但你也可以指定特定架构：

  --enable-targets=riscv64-unknown-elf,x86_64-pc-linux-gnu
  

...

7. 编译并安装

使用 make 编译 GDB，并指定使用多核编译以提高编译速度：

make -j$(nproc)

接下来，运行 make install 安装编译好的二进制文件到指定的安装目录中：

make install

遇到权限问题使用：

sudo make install

如果你不希望使用 root 权限或者不想将文件安装到 /root 目录，可以在配置时指定一个你有写权限的路径（例如：你的 home 目录）。你需要在 configure 阶段指定一个新的 --prefix 目录，如下所示：

../configure --prefix=$HOME/apps/gdb-14.2/build-riscv64 --with-python=/usr/bin/python3 --target=riscv64-unknown-elf --enable-tui=yes

8. 确认 GDB 二进制文件

生成的 GDB 二进制文件位于 build-riscv64/bin/ 目录下。通过 --version 来检查 GDB 二进制文件（相对build-riscv64目录）：

./bin/riscv64-unknown-elf-gdb --version

9. 配置环境变量

你可以将该目录（ build-riscv64/bin/）添加到系统的 PATH 环境变量中，以便在终端中全局使用 GDB：

export PATH="/root/qemu/gdb-14.2/build-riscv64/bin:$PATH"

根据你选择的安装路径修改。

为了在每次登录时自动生效，可以将该行代码添加到你的 ~/.bashrc 文件中，并执行以下命令使其立即生效：

source ~/.bashrc

确认环境变量，检查版本号：

riscv64-unknown-elf-gdb --version

10. 安装 GDB Dashboard 扩展

为了增强 GDB 的使用体验，可以安装 GDB Dashboard，它是一个用 Python 编写的启动扩展，提供了更多调试功能和用户界面。你可以使用以下命令将 GDB Dashboard 下载到 ~/.gdbinit 文件中：

wget -P ~ https://github.com/cyrus-and/gdb-dashboard/raw/master/.gdbinit

安装完成后，每次启动 GDB 时，GDB Dashboard 都会自动加载并提供更加友好的调试界面。

通过以上步骤，你就成功编译并安装了 GDB，并且安装了 GDB Dashboard 扩展工具。你现在可以使用这个定制的 GDB 来调试 RISC-V 架构的项目。

等一下，安装好了，怎么用？

GDB使用

在安装完 GDB 之后，如果你想开始使用 GDB 进行调试，了解 Makefile 是一个很好的起点。Makefile 是在构建项目时控制编译和链接过程的重要工具，它定义了如何将源代码编译为可执行文件。通过 Makefile，你可以快速完成复杂的编译工作，而不用手动输入一长串编译命令。

1. 了解 Makefile 和 GDB 调试

Makefile 是一个脚本文件，通常用于控制 C、C++ 或其他编译型语言的构建过程。它能够自动化编译、链接、清理等任务。GDB 可以用于调试你编译出来的可执行文件，因此理解 Makefile 的工作流程可以帮助你正确生成可调试的目标文件。

基本的 Makefile 结构

target: dependencies
    command

• target：目标文件（通常是编译生成的可执行文件）。
• dependencies：生成该目标文件所依赖的源文件或其他目标文件。
• command：为生成目标文件执行的命令。

基本示例

假设我们有一个简单的 C 程序 hello.c，它的内容如下：

#include <stdio.h>

int main() {
    printf("Hello, world!\n");
    return 0;
}

我们可以写一个最基本的 Makefile 来编译这个程序：

hello: hello.c
    gcc -g -o hello hello.c

• hello：这是目标文件，即生成的可执行文件。
• hello.c：这是依赖文件，指明生成 hello 需要依赖 hello.c 源代码文件。
• gcc -g -o hello hello.c：这是生成 hello 的命令，其中 -g 选项表示生成带有调试信息的可执行文件，方便后续的 GDB 调试。

请确保你在 Makefile 中使用 Tab 而不是空格来缩进命令行。

编译命令

在终端中输入以下命令执行 Makefile 以编译程序：

make

这会生成一个名为 hello 的可执行文件。

最基础的 GDB 调试例子

现在，我们有了一个带有调试信息的 hello 可执行文件，可以使用 GDB 进行调试。下面是最基础的调试步骤：

• 启动 GDB：

  gdb ./hello
  

• 运行程序：run（或简写 r）

  在 GDB 中运行可执行文件：

  run
  

• 设置断点：break（或简写 b）

  设置断点的位置，例如在 main 函数处设置断点：

  break main
  

• 单步执行：step（或简写 s）

  单步执行代码，进入函数：

  step
  

• 下一步：next（或简写 n）

  单步执行代码，但不进入函数：

  next
  

• 查看变量：print

  打印变量的值：

  print var_name
  

• 继续执行：continue（或简写 c）

  继续执行程序，直到下一个断点或程序结束：

  continue
  

• 退出 GDB：quit（或简写 q）

  退出 GDB 调试器：

  quit
  

riscv64-unknown-elf-gdb 和 gdb的区别

1. riscv64-unknown-elf-gdb：

   • 专门用于调试 RISC-V 架构的裸机程序（即不依赖操作系统的嵌入式系统开发，或类似环境）。
   • 这个工具通常与嵌入式开发的交叉编译工具链配合使用，调试的是目标平台上的代码（比如 RISC-V 处理器上的代码）。
   • 调试的程序通常是裸机（bare-metal）或者没有完整的操作系统（如实时操作系统 RTOS），通常生成的程序格式为 ELF 文件。

2. 普通的 gdb：

   • 用于调试本地的、标准操作系统（如 Linux、macOS 等）上运行的程序。
   • 这种 gdb 调试的是本地平台上的程序，比如在 x86 或 ARM 架构的机器上编译并运行的程序。
   • 它主要用于调试操作系统下运行的用户态程序，如 C/C++、Go 等编译后的可执行文件。

使用场景

• riscv64-unknown-elf-gdb：如果你在做 RISC-V 平台的开发，尤其是开发裸机程序、操作系统内核、固件或者嵌入式系统，那么这个是你要用的调试工具。

• 标准 gdb：如果你在调试本地计算机上的应用程序，或者使用标准的桌面或服务器环境来开发 C/C++ 程序，那么你应该使用普通的 gdb。

• 它们可以共存。两者是不同的工具链，分别服务于不同的架构和开发场景。在同一个系统上同时安装它们是完全可以的。你只需要根据当前调试的目标来选择合适的 gdb 版本。

总结：如果你是做嵌入式开发或者 RISC-V 开发，使用 riscv64-unknown-elf-gdb；如果是一般的桌面应用程序开发，使用本地的 gdb。

2. Hello, world!\n✖️10

下面是一个简单的 C 语言程序，它会打印 "Hello, world!" 10 次：

代码：hello.c

#include <stdio.h>

int main() {
    for (int i = 0; i < 10; i++) {
        printf("Hello, world!\n");
    }
    return 0;
}

使用 Makefile 编译

创建一个 Makefile，如下所示：

hello: hello.c
    gcc -o hello hello.c

编译和运行步骤

1. 将代码保存到文件 hello.c。

2. 创建 Makefile，并确保使用 Tab 缩进命令行。

3. 在终端运行 make 命令：

   make
   

4. 编译完成后，运行生成的可执行文件：

   ./hello
   

输出结果

Hello, world!
Hello, world!
Hello, world!
Hello, world!
Hello, world!
Hello, world!
Hello, world!
Hello, world!
Hello, world!
Hello, world!

这个程序会通过一个简单的 for 循环，打印 "Hello, world!" 10 次。

3. GDB 调试界面

下面我们来使用 GDB 调试Hello, world!✖️10：

启动 GDB

gdb ./hello

设置断点：break（或简写 b）

设置断点的位置，例如在 main 函数处设置断点：

break main

4. 运行程序：run（或简写 r）

在 GDB 中运行可执行文件：

run

1. Output/messages (输出/消息)

在这一部分，我们可以看到调试器捕获到的断点信息和程序状态：

Breakpoint 1, main () at hello.c:4
4        for (int i = 0; i < 10; i++) {

调试器在文件 hello.c 的第4行命中了断点，这是 main 函数开始的地方。通过命令 break main，调试器在进入 main() 函数的第一行代码前暂停程序执行。这个命令非常常见，尤其在调试阶段，它允许开发者从程序的主入口函数开始检查并控制执行流程。

第4行包含一个 for 循环，循环条件为 i < 10，即这个循环会执行10次。调试器在这里暂停，等待用户的进一步指令。

2. Assembly (汇编指令)

这一部分展示了与 main 函数相关的汇编代码，说明了程序在底层机器语言中的执行方式。

汇编部分展示了程序在 ARM 架构下的指令。这里的汇编指令是根据 ARM64 指令集生成的，如果这个程序运行在 x86 或其他架构下，汇编代码将会有所不同。

0xaaaaaaaaa774 <+0>:    stp     x29, x30, [sp, #-32]!
0xaaaaaaaaa778 <+4>:    mov     x29, sp
0xaaaaaaaaa77c <+8>:    str     wzr, [sp, #28]
0xaaaaaaaaa780 <+12>:   bl      0xaaaaaaaaa794 <main+40>
0xaaaaaaaaa784 <+16>:   adrp    x0, 0xaaaaaaaaa000
0xaaaaaaaaa788 <+20>:   bl      0xaaaaaaaaa650 <puts@plt>

这里的汇编代码是编译器将C代码翻译为机器可执行指令的结果。每一行表示一条指令，其中包括：

• stp 指令：保存寄存器的值，通常在进入函数时保存调用者的寄存器状态（x29和x30）。
• mov 指令：将 sp （栈指针）的值移动到 x29，用以设置帧指针。
• str 指令：将 wzr（零寄存器）的值存储到内存中，可能用于初始化变量。
• bl 指令：调用位于 main+40 的子函数。
• adrp 指令：将地址加载到寄存器中，这里是 x0。
• bl 指令：调用 puts 函数，它通常用于输出字符串。

这些指令显示了函数调用时的常见序列：保存调用者寄存器、设置栈指针、调用其他函数以及返回。

3. Breakpoints (断点)

[1]    break at 0xaaaaaaaaa774 in hello.c:4 for main hit 1 time

这段信息显示在文件 hello.c 的第4行（通过命令 break main在进入 main() 函数的第一行代码前）设置了一个断点，程序已经命中这个断点1次。这表明程序执行到这个位置后暂停下来。

4. Registers (寄存器)

x0  0xaaaaaaaaa76c    x1  0xfffffffffffb1b10    x2  0xfffffffffffb1b08    x3  0x0000000000000000
x4  0x0000000140404041    x5  0xb41c62f08fcf6c6d    x6  0x0000000000000007    x7  0x0000000000000000
x8  0xaaaaaaaaa7b0    x9  0x0000000000000001    x10 0x0000000000000000    x11 0x0000000000000000
...
x29 0xfffffffffffeec0    x30 0xaaaaaaaaa774    sp  0xfffffffffffeec0    pc  0xaaaaaaaaa774

这里列出了当前的寄存器值（在 ARM 架构下），包括通用寄存器（x0 到 x30）和栈指针（sp）、程序计数器（pc）。这些寄存器是处理器用来存储数据和指令执行的核心组件：

• x0 至 x7：常用来存储函数参数或局部变量。
• x29 和 x30：分别是帧指针（fp）和返回地址（lr）。
• sp：栈指针，指向当前栈顶位置。
• pc：程序计数器，指向当前执行的指令地址。

5. Source (源代码)

#include <stdio.h>

int main() {
    for (int i = 0; i < 10; i++) {
        printf("Hello, world!\n");
    }
    return 0;
}

这是源代码部分，展示了一个简单的C语言程序。程序在 main() 函数中使用了一个 for 循环，循环条件是 i < 10，每次循环执行 printf("Hello, world!\n"); 打印 "Hello, world!"。执行完循环后，函数返回 0，表示程序正常结束。

这段代码的主要功能是打印10次 "Hello, world!"。通过调试器的输出，我们可以看到程序在循环开始处暂停，因为我们在第4行设置了断点。

6. Stack (栈)

from 0x0000aaaaaaaaa774 in main+8 at hello.c:4

这一部分展示了调用栈，当前函数是 main，位于地址 0xaaaaaaaaa774，并且在执行第4行代码时中断。栈帧的信息可以帮助我们理解程序的执行顺序和函数调用层次。

7. Threads (线程)

id 352511 name hello from 0x0000aaaaaaaaa774 in main+8 at hello.c:4

此部分显示了当前正在运行的线程信息：

• id：线程ID，表示正在执行的线程。
• name：线程的名称，这里是 hello，与程序相关。
• from：表示线程暂停的位置，即 main 函数中的第4行代码。

8. Variables (变量)

i = 0

这一部分显示当前循环中的变量 i 的值为0。这表明 for 循环尚未执行，程序刚刚在循环开始时暂停。通过观察变量的值，开发者可以验证程序的逻辑是否按预期运行。

5. 运行后的选择

在使用 GDB 调试程序时，当我们在断点处暂停程序后，可以使用不同的命令来控制程序的执行。以下是几种常见的调试命令，它们提供了不同的执行控制方式：

1. s（step） - 逐步执行代码

step 命令用于逐行执行代码。如果当前行是一个函数调用，step 会进入该函数，并继续逐行调试函数内部的代码。这个命令特别适用于你想要深入了解函数内部逻辑的情况。

2. si（stepi） - 逐步执行汇编指令

stepi 命令用于逐条执行汇编指令，而不是按源码逐行执行。它非常适合用于低层次调试，尤其是在检查汇编代码或理解底层执行逻辑时有帮助。

3. n（next） - 下一行代码

next 命令与 step 类似，但是它不会进入函数内部。如果当前行包含一个函数调用，next 会执行整个函数，直到返回到当前函数的下一行。这个命令适用于不关心函数内部细节，而是想要快速跳过函数的情况。

4. c（continue） - 继续运行

continue 命令告诉程序继续运行，直到遇到下一个断点或程序正常结束。如果你想暂时跳过调试的细节，并观察程序是否能够完整执行，这是一个常用的命令。

5. finish - 跳出当前函数

finish 命令用于让程序继续运行，直到当前函数执行完毕并返回到调用该函数的地方。这可以帮助你快速退出正在调试的函数，而不需要逐行跟踪其余的代码。

6. 使用si 逐步执行汇编指令

这段汇编代码对应的是 main 函数的开始部分，尤其是在处理 for 循环中变量 i 的初始化和条件判断。ARM 汇编指令 str wzr, [sp, #28] 对应的就是 int i = 0 的初始化，而后续的 ldr w0, [sp, #28] 和 cmp w0, #0x9 则是对 i 进行的条件判断与循环控制。如果使用的是其他架构（如 x86），这些汇编代码会有所不同，但逻辑仍然是相同的，即通过栈帧管理和寄存器操作来处理局部变量和循环条件。

1. stp x29, x30, [sp, #-32]!

这条指令首先做了两件事：

• 保存帧指针（x29）和链接寄存器（x30）到栈中：x29 是帧指针寄存器，x30 是链接寄存器（用于存储返回地址）。这一步是为了保存调用者的上下文，以便稍后函数返回时可以恢复。
• 调整栈指针（sp）分配32字节空间：栈指针 sp 向下移动32字节，用于当前函数的局部变量和其他信息的存储。这通常是进入一个新栈帧的标准操作。

2. mov x29, sp

• 将当前栈指针 sp 的值复制到帧指针 x29：这一步的作用是更新 x29，标记当前栈帧的起始位置。x29 将作为新的帧指针，在整个函数执行期间，帮助管理局部变量和调用者栈帧的访问。

3. str wzr, [sp, #28]（当前位置，si后发生）

• 将 wzr（零寄存器）的值存储到栈上的某个偏移位置：在 ARM 中，wzr 是一个常量寄存器，总是等于零。这里将 0 存储在栈指针偏移 28 字节的位置。这很可能是初始化局部变量 int i，因为在 C 代码的 for (int i = 0; i < 10; i++) 中，i 初始化为 0。

根据标准 C 代码编译后的行为，i 很可能被分配到栈上偏移量 28 的位置，这条指令是在初始化 i 为 0。

si

接下来发生的事情

4. bl 0xaaaaaaaaa794 <main+40>

• 分支并链接：bl 指令将跳转到 main+40 处，保存当前的返回地址到 x30。在 main+40，你给出的代码展示了下一组与 for 循环控制有关的汇编指令。

继续si，跳转到 main+40 处

5. ldr w0, [sp, #28]

• 从栈中加载 i 的值：这里从栈的 28 字节偏移处（也就是之前存储 i 的位置）加载值到寄存器 w0。此时 w0 的值是 0，因为之前将 0 存入了栈中的该位置。

在 ARM64 架构中，w0 是一个 32 位的通用寄存器，它经常用于存储函数的返回值或者函数参数。在调试过程中，特别是在使用 GDB 的时候，我们可以直接查看寄存器的值，包括 w0。

3. 查看寄存器： 在 GDB 中，可以使用以下命令来查看所有寄存器的值，info registers：

   (gdb) info registers
   

   输出将包含所有通用寄存器的值，包括 w0。例如，你可能会看到如下输出：

   x0   0x0000000000000001    w0   0x00000001
   x1   0x0000000000000000    w1   0x00000000
   x2   0x0000000000000000    w2   0x00000000
   

   其中，x0 是 64 位寄存器，而 w0 是它的低 32 位部分。w0 的值就是寄存器 w0 当前存储的 32 位数据。

4. 单独查看 w0： 如果你只想单独查看 w0 的值，可以使用以下命令：

   (gdb) print $w0
   

   GDB 会输出寄存器 w0 的当前值，例如：

   $1 = 1
   

5. 单步执行并查看： 如果你想在单步执行指令时查看 w0 的值，可以使用 step 或 next 命令进行单步调试，每执行一步都可以使用 info registers 或 print $w0 来查看 w0 的更新情况。

si

6. cmp w0, #0x9

• 比较寄存器 w0（i 的值）和 9：这是 for (int i = 0; i < 10; i++) 循环的条件部分。这里 i 被比较是否小于等于 9（即 i < 10）。

si

7. b.le 0xaaaaaaaaa77c <main+16>

• 条件跳转：如果 w0（i 的值）小于等于 9，则跳转到 main+16，也就是循环体部分。如果条件为真，这会跳回到之前执行的部分，循环继续。

关联到 C 代码中的 for (int i = 0; i < 10; i++)

结合汇编代码与 C 代码，流程如下：

1. 在进入 main 函数时，栈帧被设置，局部变量 i 被分配到栈的偏移 28 字节的位置。
2. str wzr, [sp, #28] 将 i 初始化为 0。
3. 程序执行循环条件检查，ldr w0, [sp, #28] 从栈中加载 i 的值，cmp w0, #0x9 与 9 进行比较。
4. 如果 i <= 9，则通过 b.le 跳转回循环体，执行 printf("Hello, world!\n") 语句，之后再递增 i，继续下一次循环。
5. 当 i 超过 9，循环结束，程序跳出 for 循环。

7. 进入循环

s（或者3个si）

这段代码表示调用了 puts 函数，并且在调用 puts 之前对寄存器 x0 进行了修改：

0x0000aaaaaaaaa77c  main+16 adrp   x0, 0xaaaaaaaaa000
0x0000aaaaaaaaa780  main+20 add    x0, x0, #0x850
0x0000aaaaaaaaa784  main+24 bl     0xaaaaaaaaa650 <puts@plt>

1. adrp x0, 0xaaaaaaaaa000 (0x0000aaaaaaaaa77c):

   • 这是 ARM64 中的“Page-relative address”指令，用来加载一个基址（page address）到寄存器 x0。在这里，它将地址 0xaaaaaaaaa000 的页基址加载到 x0。

2. add x0, x0, #0x850 (0x0000aaaaaaaaa780):

   • 将 x0（基址）加上偏移量 0x850。这个操作的目的是构建一个完整的地址，用于后续操作。这种模式在调用外部函数时很常见，比如准备 puts 函数的参数。

3. bl 0xaaaaaaaaa650 <puts@plt> (0x0000aaaaaaaaa784):

   • bl（Branch with Link）是 ARM64 中的函数调用指令。在这里，它调用了 puts@plt，这是一个外部函数 puts 的地址。x0 中的值通常会被用来作为函数参数传递给 puts。
   • 在这个调用中，x0 存储了 puts 的参数（通常是一个指向要打印的字符串的地址）。

这里即将进入printf函数。

8. 函数调用规则

参见 xv6 || CS61C || MIT6.004

printf 或者 puts 这样的函数调用会使用 w0 寄存器（或者更广泛的 x0 寄存器）来传递函数参数。在 ARM64 架构中，函数参数通常通过寄存器传递，w0 或者 x0（根据参数的大小，使用 32 位的 w0 或 64 位的 x0）是第一个用于传递参数的寄存器。

在 ARM64 架构中，w0 和 x0 寄存器（分别为 32 位和 64 位寄存器）是第一个用于函数参数传递的寄存器，通常函数调用过程中会修改这些寄存器。实际上，函数调用的过程中，寄存器 w0 或 x0 不仅仅是 printf 或 puts 会修改，几乎所有的函数调用，只要它需要传递参数或者返回值，都会对这些寄存器进行使用和修改。

ARM64 函数调用规则（AArch64 ABI）

ARM64 的调用约定（ABI, Application Binary Interface）定义了函数如何传递参数和接收返回值。根据这个约定：

1. 参数传递：

   • 函数的前 8 个参数通过寄存器 x0 到 x7 传递。如果是 32 位参数，会用到寄存器的低 32 位，也就是 w0 到 w7。
   • w0 和 x0 是第一个用于传递参数的寄存器，因此任何需要第一个参数的函数都会使用 w0 或 x0。

2. 返回值传递：

   • 函数返回值也是通过 x0 或 w0 传递的。如果函数有返回值（无论是整数、指针等），该值会存储在 x0 或 w0 中。所以，当一个函数返回时，你可以在 x0 或 w0 中找到返回值。

3. 函数调用后，w0 和 x0 的值变化：

   • 如果函数有返回值，调用完函数后 x0 或 w0 中会包含返回值。
   • 如果函数没有返回值，x0 或 w0 的值可能没有明确规定，因此在调用之后可能会被修改，不能再依赖它保存之前的值。

更广泛的修改 w0 或 x0 的情景

以下是一些更常见的情景，展示了在函数调用过程中如何修改 w0 或 x0：

1. 参数传递时：

   • 任何需要传递第一个参数的函数调用都会使用 w0 或 x0。无论是标准库函数、用户定义的函数还是系统调用，它们都会将第一个参数存储在 w0 或 x0 中。

   示例：

   mov w0, #10       // 将整数 10 存储到 w0，作为第一个参数传递
   bl my_function    // 调用函数 my_function(w0=10)
   

2. 函数返回值：

   • 如果函数有返回值，返回值通常会放在 w0 或 x0 中。如果函数调用后你检查 w0，看到的值通常是函数的返回结果，而不再是之前的循环变量或其他值。

   示例：

   bl my_function    // 调用函数 my_function
   mov x1, x0        // 将返回值（保存在 x0 中）存储到 x1
   

3. 系统调用：

   • 在 ARM64 架构下，系统调用也是通过寄存器传递参数。x0 是传递给系统调用的第一个参数的寄存器，同时系统调用的返回值也通过 x0 传递。

   示例：

   mov x8, #93       // 系统调用号（例如 exit）
   mov x0, #0        // 将 0 作为系统调用的第一个参数
   svc #0            // 发出系统调用
   

4. 库函数调用：

   • 类似 printf、malloc 等库函数也会使用 x0 或 w0 来传递参数。对于这些函数来说，它们会读取 w0 中的值，并在其完成时修改 w0，以传递返回值。

当前我们依旧处于即将进入printf函数的位置。

在函数调用之前查看 w0 的值：

info registers w0

或

print $w0

可以看到当前i的值为0。

接下来如果使用si，你将进入printf函数的实现，这里我们选择忽略内部的实现，使用next跳转到直接执行完printf函数的位置，你也可以尝试si和finish执行完printf函数。

n

在函数返回后查看返回值：

如果函数返回一个值，w0 或 x0 中将存储这个值。对于 32 位返回值，使用 w0，对于 64 位返回值，使用 x0。

9. printf 函数

printf 是 C 标准库中的一个非常常用的函数，它用于格式化输出。它的功能可以概括为：接受一系列参数，根据指定的格式化字符串，将这些参数转换为对应的字符串，然后输出到标准输出（通常是控制台）上，并返回成功输出的字符数量。

printf 函数的工作原理概述

1. 函数声明：

   int printf(const char *format, ...);
   

   • const char *format：格式化字符串，定义了输出内容的结构、顺序和格式。
   • ...：可变参数，这些是根据 format 字符串指定的类型，传递给 printf 的数据。
   • 返回值：printf 的返回值是成功打印的字符总数。

2. 参数的解释：

   • 格式化字符串：printf 第一个参数是格式化字符串，其中可以包括文字和格式说明符（如 %d, %s, %f 等）。这些说明符告诉 printf 如何处理后面的参数。
   • 可变参数：printf 函数是一个“可变参数”函数（variadic function），它可以接受任意数量和类型的参数，但这些参数的数量和类型必须与格式化字符串中的说明符相匹配。

3. 返回值：

   • printf 成功执行后，会返回它实际输出的字符数（包括空格和换行符等）。如果发生错误，printf 返回一个负值。

printf 内部工作流程

printf 的内部工作可以概括为以下步骤：

1. 解析格式化字符串： printf 首先解析它接收到的第一个参数，即格式化字符串。它会从左到右扫描字符串，直到遇到格式说明符（如 %d, %s, %f）。这些格式说明符指示 printf 如何格式化后续的参数。

2. 处理可变参数： 对于每一个格式说明符，printf 会依次从剩余的可变参数列表中获取对应类型的参数。然后，它将这个参数格式化为对应的字符串表示。

   • 如果遇到 %d，printf 会从参数中获取一个 int 类型的值，并将其格式化为十进制数字。
   • 如果遇到 %s，printf 会从参数中获取一个 char* 类型的字符串，并将其直接打印。
   • 如果遇到 %f，printf 会从参数中获取一个 float 或 double 类型的浮点数，并将其格式化输出。

3. 格式化输出： printf 将解析的内容和从参数中提取的值组合在一起，然后输出到标准输出（通常是控制台）。

4. 返回输出字符数： printf 在成功输出所有内容后，会返回打印到标准输出的字符数。这包括所有输出的字符，但不包括最终的 \0 终止符。

printf 函数的示例

以下是一个简单的例子，展示 printf 的参数如何与格式化字符串结合使用：

int main() {
    printf("Hello, world!\n");
    return 0;
}

在这个例子中，printf 输出的字符串是 "Hello, world!\n"。如果你数一数，这个字符串包含 14 个字符：

• Hello, world! 是 13 个字符。
• \n 是换行符，算作一个字符。

因此，printf 返回的值是 14，表示总共输出了 14 个字符。

10. 继续循环

si

这段汇编代码回到了 ARM64 架构下的for循环执行过程，具体是在一个循环体中对变量 i 进行加载、加1、比较的操作。对应的 C 代码中的循环部分：

for (int i = 0; i < 10; i++) {
    // do something
}

1. ldr w0, [sp, #28] (地址：0x0000aaaaaaaaa788)

• ldr（Load Register）：从内存中加载数据到寄存器。
• w0：表示 ARM64 的 32 位通用寄存器 w0，存储的是变量 i 的值。
• [sp, #28]：表示从栈指针（sp）加上偏移量 28 个字节的位置读取数据，加载到寄存器 w0 中。

解释： 这里的指令从内存中读取变量 i（存储在栈中 sp + 28 的位置），并将其加载到 w0 寄存器中，供后续操作使用。

2. add w0, w0, #0x1 (地址：0x0000aaaaaaaaa78c)

• add：加法运算。
• w0, w0, #0x1：将寄存器 w0 的值加 1，并将结果保存在 w0 中。

解释： 这里的指令对 w0（也就是变量 i）的值加 1，更新后的值存储回 w0。

3. str w0, [sp, #28] (地址：0x0000aaaaaaaaa790)

• str（Store Register）：将寄存器中的值存储到内存中。
• w0：这是存储 i 变量的新值的寄存器。
• [sp, #28]：表示将寄存器 w0 中的值存储到栈指针 sp 偏移量为 28 的位置。

解释： 将更新后的变量 i（即 w0 中的值）存回栈中的 sp + 28 位置。

4. ldr w0, [sp, #28] (地址：0x0000aaaaaaaaa794)（与 main 函数开始时重复）

• ldr（Load Register）：从内存中加载数据到寄存器。
• [sp, #28]：表示从 sp 偏移 28 个字节的位置加载数据到 w0。

解释： 再次将变量 i（存储在 sp + 28 的位置）的值加载到寄存器 w0 中，准备进行比较。

5. cmp w0, #0x9 (地址：0x0000aaaaaaaaa798)

• cmp（Compare）：比较两个值，常用于控制流中的分支判断。
• w0, #0x9：比较 w0 中的值（即变量 i 的值）与 9。

解释： 这里进行比较，判断变量 i 的值是否小于 10（i < 10），为后续控制流做准备。如果 i 小于 10，则继续循环；否则跳出循环。

6. b.le 0xaaaaaaaaa77c <main+16>

• 条件跳转：如果 w0（i 的值）小于等于 9，则跳转到 main+16，也就是循环体部分。如果条件为真，这会跳回到之前执行的部分，循环继续。

汇总解释

这段代码展示了一个典型的 for 循环核心操作：

1. 从内存中加载循环变量 i 的当前值。
2. 将 i 加 1。
3. 更新内存中的 i 值。
4. 再次加载 i，并与 9 进行比较，决定是否继续执行循环。

这些指令就是实现 for (int i = 0; i < 10; i++) 的循环控制逻辑。

11. 继续运行到退出

接下来你可以尝试多次n，同时观察i和寄存器x0的值，大概变化像这样0 14 1 14 2 14 3 14...，直到循环结束退出。

Makefile似乎没怎么用上？

我们可以开头的Makefile 中添加 GDB 的调试目标，这样可以方便你使用 GDB 进行调试。基本的 Makefile 将生成一个可执行文件 hello，并且支持使用 GDB 进行调试。

在原来的 Makefile 基础上，我们添加一个名为 debug 的目标来启动 GDB。具体操作如下：

修改后的 Makefile

# 定义目标文件
hello: hello.c
    gcc -g -o hello hello.c

# 运行程序
run: hello
    ./hello

# 定义调试目标
debug: hello
    gdb ./hello

# 定义清理目标，删除生成的文件
clean:
    rm -f hello

解释

1. hello: hello.c:

   • 这表示生成目标文件 hello 需要依赖源文件 hello.c。
   • gcc -g -o hello hello.c: 使用 GCC 编译生成 hello，并且通过 -g 选项生成带有调试信息的可执行文件，方便后续调试。

2. 运行程序目标 run：

   • run: hello：这个目标依赖于 hello，确保可执行文件已经生成。
   • ./hello：执行生成的 hello 程序。

3. gdb: hello:

   • 这是一个新的目标，名字是 gdb，它依赖于目标 hello。也就是说，执行 make gdb 会首先确保生成可执行文件 hello，然后运行 GDB。
   • gdb ./hello: 通过 GDB 启动 hello 可执行文件，方便进行调试。

4. clean:

   • 这是一个清理目标，用于删除生成的 hello 文件，保持工作目录整洁。
   • rm -f hello: 强制删除 hello，不会提示错误。

使用方法

1. 运行 make 或 make hello 来编译程序。

   make
   

2. 输入 make run 来运行编译生成的 hello 程序。

   make run
   

3. 运行 make gdb 来启动 GDB 并调试 hello。

   make gdb
   

4. 运行 make clean 来清理生成的可执行文件。

   make clean
   

现在这个 Makefile 可以完成编译 hello.c 并生成可执行文件 hello。当你需要使用 GDB 进行调试时，只需要运行 make gdb，它会自动启动 GDB 并加载可执行文件 hello，方便调试工作。

通俗地说，Makefile 是一种用于自动化编译和管理项目中文件依赖的工具。它的主要作用是通过定义规则告诉计算机如何编译和链接项目中的源代码文件，省去你每次手动输入命令的麻烦。下面是一个更加直观的解释：

1. Makefile 是什么？

Makefile 就像一张“说明书”，告诉编译器和开发工具应该怎么去处理你的代码。想象一下，你有一个项目，有很多源代码文件，比如 .c 文件或者 .cpp 文件。这些文件需要被编译成一个最终的可执行文件，而 Makefile 就是用来组织、管理和自动执行这些步骤的工具。

• 为什么要用 Makefile？
  • 如果项目有很多文件，你不需要每次手动输入命令来编译、链接这些文件。
  • Makefile 能追踪文件的变化，只编译那些发生了变化的文件，节省时间。
  • 它让编译的步骤更有条理，一次输入命令就可以自动完成很多操作。

2. Makefile 的基本构造

一个简单的 Makefile 包含两部分内容：

1. 目标文件（想生成的文件，通常是可执行文件）。
2. 规则（告诉你如何生成目标文件）。

举个例子

假设你有一个源代码文件叫 hello.c，它是用 C 编写的程序。你希望生成一个叫 hello 的可执行文件。你平常需要手动输入这样的命令来编译它：

gcc -o hello hello.c

这次，我们可以写一个最简单的 Makefile：

hello: hello.c
    gcc -o hello hello.c

3. 如何理解这个 Makefile？

• hello: hello.c：这里 hello 是目标，表示我们想生成的文件是 hello。hello.c 是依赖文件，表示 hello 的生成依赖于 hello.c 这个源代码文件。
• gcc -o hello hello.c：这一行就是生成 hello 可执行文件的具体指令。它告诉 make：当你看到 hello.c 发生变化时，使用 gcc 来编译它，并生成可执行文件 hello。

4. Makefile 的工作原理

当你在终端输入 make 时，make 会去找当前目录中的 Makefile，然后按照里面的指令执行编译。

• 如果源代码没有变动，make 会判断出不需要重新编译，跳过这一步。
• 如果源代码文件改变了，make 会重新编译生成新的可执行文件。

5. 更多功能：自动化和清理

你可以让 Makefile 做的不仅仅是编译程序，还可以让它帮助你自动化一些工作，比如清理不需要的文件（比如编译生成的中间文件）。

添加一个清理规则

hello: hello.c
    gcc -o hello hello.c

clean:
    rm hello

• clean：这是一个新添加的规则，用于删除生成的 hello 文件。
• rm hello：这个命令会删除 hello 可执行文件。

现在，如果你输入 make clean，它就会执行 rm hello 命令，帮你清理掉生成的文件。

6. 完整示例：添加调试和运行规则

假设你还想要运行程序、用 GDB 调试或者清理文件，那么 Makefile 可以做更多的事：

hello: hello.c
    gcc -g -o hello hello.c   # 生成带调试信息的可执行文件

run: hello
    ./hello                  # 运行程序

gdb: hello
    gdb ./hello              # 用 GDB 调试程序

clean:
    rm -f hello              # 清理生成的文件

• run：编译好后运行程序。
• gdb：用 GDB 调试程序。
• clean：清理生成的可执行文件。

7. 为什么 Makefile 有用？

• 简化复杂的编译流程：如果你有很多源代码文件，它们相互依赖，Makefile 能够根据这些依赖来确定如何自动编译所有文件，而不需要你一个个去编译。
• 节省时间：如果某个文件已经编译好了，没有修改，Makefile 不会重新编译它，只会编译发生了变化的文件。
• 自动化项目管理：不仅仅可以用来编译，还可以用来运行程序、清理临时文件，甚至自动化测试。

明白了，让我们开始调试操作系统吧！

riscv64-unknown-elf-gdb和QEMU

接下来我们将结合使用 riscv64-unknown-elf-gdb 和 QEMU 来调试 RISC-V 的程序。QEMU 是一个开源的模拟器，它可以用来模拟不同架构的硬件环境，而 riscv64-unknown-elf-gdb 则是专门为 RISC-V 目标编译的 GDB 调试器。回顾riscv64-unknown-elf-gdb 和 gdb的区别。

一、尝试 Hello, world!\n✖️10

将上节的hello.c复制到一个新的文件夹，我们来尝试使用 riscv64-unknown-elf-gdb 和 QEMU 在 RISC-V 架构下调试它。

1. 编译 RISC-V 程序

首先将hello.c程序为 RISC-V 架构编译。可以使用如下的 gcc 命令来编译你的程序：

riscv64-unknown-elf-gcc -g -o hello hello.c

• -g 选项会确保编译后的程序包含调试信息，方便 GDB 使用。
• hello.c 是你的源代码文件，hello 是编译生成的目标文件（RISC-V 架构的可执行文件）。

2. 使用 QEMU 运行 RISC-V 程序

接下来，我们使用 QEMU 来模拟 RISC-V 环境并运行刚刚编译的 hello 程序。命令如下：

qemu-system-riscv64 -machine virt -nographic -kernel hello.elf -s -S

• -machine virt：选择 QEMU 中的虚拟 RISC-V 机器。
• -nographic：表示不使用图形界面，所有输出通过当前终端处理。
• -kernel hello：指定要加载并运行的 RISC-V 程序。
• -s：启用调试模式，会在端口 1234 上开启一个 GDB 服务器。
• -S：告诉 QEMU 在启动后暂停 CPU，这样我们可以连接 GDB 进行调试，而不会立即运行程序。

此时，QEMU 会启动，但它会处于暂停状态，等待 GDB 连接。

3. 使用 riscv64-unknown-elf-gdb 连接 QEMU

现在，我们使用 GDB 连接到 QEMU 并调试程序。首先启动 riscv64-unknown-elf-gdb：

riscv64-unknown-elf-gdb hello.elf

• hello.elf 是之前编译的可执行文件，GDB 会加载它的调试信息。

然后在 GDB 中输入以下命令，连接到 QEMU 的调试服务器：

(gdb) target remote localhost:1234

• 这里的 localhost:1234 是 QEMU 默认开启的调试端口。

4. 设置断点和调试

现在，你已经成功连接到了 QEMU 模拟的 RISC-V 环境，可以开始调试了。

报错1：等一下？我的第一步编译就出错了

二、RISC-V 裸机编程

在RISC-V裸机编程（bare-metal programming）中，将无法再使用 stdio.h 这样的标准C库头文件，主要原因是裸机编程与操作系统环境的差异。以下是详细的解释：

1. 裸机编程与操作系统的区别

在操作系统（如 Linux、Windows 等）上，C 标准库（包括 stdio.h）依赖操作系统提供的功能和服务来执行输入输出等操作。例如，printf 函数依赖于操作系统提供的系统调用（system call），将数据发送到标准输出设备（如屏幕或终端）。操作系统会管理这些资源和设备，提供文件系统、内存管理、硬件抽象等功能。

而裸机编程中，程序直接运行在硬件上，没有操作系统的帮助，也没有提供类似的系统调用接口。因此，诸如 stdio.h 头文件中定义的标准输入输出函数（如 printf、scanf）都无法工作，因为它们依赖于操作系统来管理硬件资源。

2. stdio.h 的功能依赖

stdio.h 提供的功能主要用于标准输入输出流的操作，包括文件的读取写入和格式化输出。这些功能在操作系统环境下是通过一系列系统调用（例如 POSIX 标准中的 write()、read()）实现的。而在裸机环境中：

• 没有文件系统：裸机程序没有操作系统提供的文件系统来管理文件，因此标准输入输出流无法找到目标文件或设备。
• 没有设备驱动程序：操作系统负责管理设备（如显示器、键盘、网络接口等）并提供驱动程序。裸机程序则必须直接操作硬件寄存器与外设通信，而标准库无法提供这样的功能。

例如，在操作系统上使用 printf 输出信息时，实际执行的是系统调用，操作系统会将格式化的字符串写入标准输出设备。而在裸机程序中，没有系统调用，因此 printf 无法正常工作。

3. 替代方案：SBI 调用或直接访问硬件

在裸机环境中，可以通过以下方式来实现与外界的交互：

1) SBI（Supervisor Binary Interface）调用

在 RISC-V 裸机编程中，通常依赖 SBI（Supervisor Binary Interface）提供的接口来执行某些基本的硬件操作。SBI 是 RISC-V 中一个运行在特权模式下的小型运行环境，提供了裸机程序和硬件之间的抽象接口。例如，使用 ecall 指令与 SBI 通信，可以执行控制台输出、关机、时间中断等操作。

类似下面的 sbi_call() 函数，通过 SBI_CONSOLE_PUTCHAR 实现字符输出，而不是使用 stdio.h 的 printf。

#define SBI_CONSOLE_PUTCHAR 0x1

static inline void sbi_call(uint64_t sbi_num, uint64_t arg0) {
    register uint64_t a0 asm ("a0") = arg0;
    register uint64_t a7 asm ("a7") = sbi_num;
    asm volatile ("ecall" : "+r"(a0) : "r"(a7) : "memory");
}

void print_char(char c) {
    sbi_call(SBI_CONSOLE_PUTCHAR, c);
}

2) 直接访问硬件

在裸机环境中，常常需要直接操作硬件设备，比如直接写入硬件寄存器来控制串口输出。以 UART（通用异步收发传输器）为例，裸机程序可以通过直接访问串口的寄存器，实现字符的输出和输入，而不需要依赖 stdio.h。

4. RISC-V 裸机编程中的常见输入输出方式

1. UART 串口输出：裸机程序可以通过访问 UART 寄存器，发送数据到终端设备。对于很多裸机程序来说，UART 是最常见的调试输出手段。

2. SBI 调用：RISC-V 提供了 SBI 规范，在裸机程序中，可以通过 ecall 指令与 SBI 交互，完成输出字符到控制台的功能，如上面的代码中通过 SBI_CONSOLE_PUTCHAR 实现字符输出。

5. 在裸机环境中使用 Rust 和 core 库

在 Rust 裸机编程 中，由于没有操作系统的支持，标准库 (std) 同样是不能使用的。因为标准库依赖操作系统提供的功能（如文件系统、网络等）。但是，core 库 是可以使用的，因为它是 no_std 环境中的基础库，不依赖操作系统的功能。

core 库提供了许多基础功能，比如基础的数据类型、数学运算、内存操作等，但不包括 I/O、线程、文件操作等。这样就允许在没有操作系统的裸机环境下编写 Rust 代码。更多内容见下一节。

三、不使用标准库的 Hello World C 代码

现在我们需要将 Hello, world!\n✖️10 替换为一个不使用标准库的 Hello World C 代码。

下面是一个不带标准库的 "Hello, World" C 程序，适用于 riscv64-unknown-elf-gdb 和 QEMU 模拟的 RISC-V 环境。我们将使用 RISC-V 的 SBI（Supervisor Binary Interface）来进行字符输出。

不使用标准库的 Hello World C 代码（适用于 RISC-V 裸机编程）

// hello.c

// 定义标准整数类型（手动定义）
typedef unsigned long long uint64_t;
typedef unsigned int uint32_t;
typedef unsigned char uint8_t;

#define SBI_CONSOLE_PUTCHAR 0x1

static inline void sbi_call(uint64_t sbi_num, uint64_t arg0, uint64_t arg1, uint64_t arg2) {
    register uint64_t a0 asm ("a0") = arg0;
    register uint64_t a1 asm ("a1") = arg1;
    register uint64_t a2 asm ("a2") = arg2;
    register uint64_t a7 asm ("a7") = sbi_num;
    asm volatile ("ecall"
                  : "+r"(a0)
                  : "r"(a1), "r"(a2), "r"(a7)
                  : "memory");
}

void print_char(char c) {
    sbi_call(SBI_CONSOLE_PUTCHAR, c, 0, 0);
}

void print_string(const char* str) {
    while (*str) {
        print_char(*str++);
    }
}

int main() {
    print_string("Hello, World! x10 (fake)\n");
    while (1) {} // 无限循环，防止程序退出
    return 0;
}

代码说明

1. 手动定义固定宽度整数类型：由于 stdint.h 无法使用，我们手动定义了常见的固定宽度整数类型，比如 uint64_t、uint32_t 和 uint8_t。
   • typedef unsigned long long uint64_t;：定义 64 位无符号整数。
   • typedef unsigned int uint32_t;：定义 32 位无符号整数。
   • typedef unsigned char uint8_t;：定义 8 位无符号整数。
2. SBI 调用：我们使用 RISC-V 的 SBI（Supervisor Binary Interface）来向控制台输出字符。SBI 是一种操作系统与底层硬件通信的接口，类似于 x86 架构的 BIOS 中断。
   • SBI_CONSOLE_PUTCHAR：SBI 提供了控制台输出字符的接口，这个接口编号是 0x1。
3. sbi_call 函数：使用内联汇编指令 ecall 实现的 SBI 调用，用于与硬件交互。
4. print_char 函数：调用 sbi_call 向控制台输出单个字符。
5. print_string 函数：循环调用 print_char 来输出字符串。
6. main 函数：程序的入口，调用 print_string 输出 "Hello, World! x10 (fake)"，之后进入无限循环，防止程序退出。

详细代码说明

1. 定义标准整数类型

typedef unsigned long long uint64_t;
typedef unsigned int uint32_t;
typedef unsigned char uint8_t;

这三行代码定义了标准的无符号整数类型：

• uint64_t 是无符号 64 位整数（unsigned long long）。
• uint32_t 是无符号 32 位整数（unsigned int）。
• uint8_t 是无符号 8 位整数（unsigned char）。

这些类型通常在裸机编程中用于确保明确的位宽，因为不同平台上 int 和 long 的位宽可能有所不同。

代码内容只使用了uint64_t，为了增加代码的健壮性和可移植性，手动定义了额外的整数类型（32 位和 8 位），即便它们在这段代码中没有直接用到。

2. SBI Console Putchar 定义

#define SBI_CONSOLE_PUTCHAR 0x1

这是一个宏定义，用于指定 SBI 调用的编号。SBI_CONSOLE_PUTCHAR 的值为 0x1，它是 RISC-V SBI 调用接口中的一个标识符，用于向控制台输出一个字符。

SBI（Supervisor Binary Interface）是 RISC-V 的一个标准接口，允许裸机程序（运行在机器模式或超级模式的程序）通过 ecall 指令与底层固件（如 OpenSBI）交互。SBI_CONSOLE_PUTCHAR 是 SBI 的一部分，专门用于字符输出。

3. SBI 调用实现

static inline void sbi_call(uint64_t sbi_num, uint64_t arg0, uint64_t arg1, uint64_t arg2) {
    register uint64_t a0 asm ("a0") = arg0;
    register uint64_t a1 asm ("a1") = arg1;
    register uint64_t a2 asm ("a2") = arg2;
    register uint64_t a7 asm ("a7") = sbi_num;
    asm volatile ("ecall"
                  : "+r"(a0)
                  : "r"(a1), "r"(a2), "r"(a7)
                  : "memory");
}

解释：

1. 函数定义：sbi_call 是一个内联函数（inline 函数），表示编译器在调用该函数时不会产生实际的函数调用，而是将函数体嵌入到调用该函数的位置，从而避免函数调用的开销。该函数通过汇编指令 ecall 来执行 SBI 调用。

2. 寄存器绑定：

   • register uint64_t a0 asm ("a0") = arg0; 通过 asm ("a0") 将 C 语言中的变量 arg0 绑定到 RISC-V 的 a0 寄存器。
   • 同理，a1、a2 分别绑定到 RISC-V 的 a1 和 a2 寄存器，a7 寄存器绑定到 sbi_num，即 SBI 调用编号。

3. 汇编指令 ecall：

   • ecall 是 RISC-V 中的一个特权指令，用于在机器模式（M-mode）或超级模式（S-mode）下执行系统调用（类似于 x86 架构中的 syscall 指令）。此指令触发陷入系统的特权模式，通过 SBI 与底层固件交互。
   • asm volatile 声明告诉编译器不要优化掉这个汇编块，并且要确保其副作用会被执行。

4. 输入输出约束：

   • "+r"(a0) 表示 a0 寄存器会在调用前后都被使用，并且在调用过程中可能被修改（"read-write"）。
   • "r"(a1), "r"(a2), "r"(a7) 表示 a1、a2 和 a7 作为输入寄存器，指令只会读取这些寄存器的值。
   • "memory" 表示该汇编指令会对内存有影响，防止编译器对内存操作进行重排。

在 RISC-V 的 SBI 调用中，有时可能需要传递多个参数。在这里可以只传递一个字符数据，即 arg1 和 arg2 是不必要的，直接使用两个参数即可。

提供额外的 arg1 和 arg2 参数，是为了更通用的用途。尽管在 print_char 中不需要这些参数，但这使得 sbi_call 更加通用，可以在其他场景中使用更多的寄存器传递额外信息。

使用两个参数的版本

static inline void sbi_call(uint64_t sbi_num, uint64_t arg0) {
    register uint64_t a0 asm ("a0") = arg0;
    register uint64_t a7 asm ("a7") = sbi_num;
    asm volatile ("ecall"
                  : "+r"(a0)
                  : "r"(a7)
                  : "memory");
}

总结：

该函数通过 ecall 发起系统调用，并使用 a0 到 a7 寄存器传递参数。a0 是返回值寄存器，而 a7 用于传递 SBI 编号，a1 和 a2 用于传递额外的参数。

4. 输出字符

void print_char(char c) {
    sbi_call(SBI_CONSOLE_PUTCHAR, c, 0, 0);
}

解释：

print_char 函数用于输出一个字符。它调用了 sbi_call 函数，将 SBI_CONSOLE_PUTCHAR 作为 sbi_num，并将字符 c 作为第一个参数（通过 a0 寄存器传递）。arg1 和 arg2 被设置为 0，因为字符输出不需要额外的参数。

5. 输出字符串

void print_string(const char* str) {
    while (*str) {
        print_char(*str++);
    }
}

解释：

print_string 函数用于输出一个字符串。它通过指针 str 遍历字符串的每个字符，调用 print_char 输出每个字符，直到遇到字符串末尾的空字符（'\0'）。每次输出一个字符后，str++ 使指针指向下一个字符。

6. 主函数

int main() {
    print_string("Hello, World! x10 (fake)\n");
    while (1) {} // 无限循环，防止程序退出
    return 0;
}

解释：

1. 字符串输出：main 函数中调用了 print_string，输出字符串 "Hello, World! x10 (fake)\n" 到控制台。

2. 无限循环：while (1) {} 是一个空的无限循环，用于防止程序在输出完成后退出。这是因为在裸机环境中，没有操作系统管理程序的退出行为。如果没有这个循环，程序会继续执行到未定义的内存区域，可能导致未定义行为甚至崩溃。

将hello.c内容替换为以上不使用标准库的 Hello World C 代码，再次尝试编译：

riscv64-unknown-elf-gcc -g -o hello hello.c

报错2：还是报错：找不到crt0.o、-lc 和 -lgcc

四、不使用默认的启动代码

crt0.o、-lc 和 -lgcc 是编译和链接过程中的重要组成部分，通常在操作系统环境下使用。在裸机编程环境中，编译器报错找不到这些文件或库，原因还是裸机编程的环境与操作系统支持的环境截然不同。

1. crt0.o（C Runtime Object File）

crt0.o 是 C 语言运行时库（C runtime）的启动代码（C runtime startup code）。它是一个对象文件，通常在链接阶段被包含进程序，用于为 C 语言程序的运行做准备。它的主要职责是：

• 设置程序的入口点（通常是 _start）。
• 初始化全局和静态变量。
• 调用 main 函数。
• 程序退出时执行清理操作。

在操作系统中的角色

在操作系统（如 Linux）上，crt0.o 会做如下工作：

• 设置栈指针。
• 初始化 .bss 和 .data 段。
• 调用操作系统提供的动态链接器，加载共享库。
• 最后调用 main 函数。

在裸机编程中的问题

在裸机编程中，没有操作系统和动态链接器，也不需要操作系统提供的初始化工作。因此，裸机程序通常自行编写启动代码，手动设置栈指针、初始化 .bss 和 .data 段等工作。这就是为什么在裸机环境下不需要 crt0.o，并且会报错找不到它。你需要**提供自己专门的启动文件（通常是汇编代码）**来替代 crt0.o 的功能，比如一个 start.s 文件。

2. -lc（C Standard Library）

-lc 是指链接标准 C 库（libc）。C 标准库提供了许多基本的功能，比如：

• 输入输出（printf、scanf 等）。
• 字符串处理（strlen、strcpy 等）。
• 数学运算（sin、cos 等）。

在操作系统中的角色

在有操作系统支持的环境中，C 标准库依赖操作系统提供的系统调用来实现许多功能。例如，printf 函数通过系统调用将字符串输出到控制台，而文件操作、内存分配等功能也都依赖操作系统的支持。

在裸机编程中的问题

裸机编程没有操作系统，因此也没有文件系统、终端或控制台等资源供标准 C 库调用。例如，裸机程序无法调用 printf，因为没有操作系统提供的输入输出设备支持。所以在裸机编程中，标准 C 库是无用的，链接 -lc 会导致错误。

为了解决这个问题，裸机编程通常需要自己编写或者使用特定的库来替代部分 libc 的功能，比如通过访问硬件寄存器或使用 SBI 来实现字符输出。你不能直接使用操作系统依赖的 libc，而是需要为裸机环境定制输出、内存管理等基本功能。

3. -lgcc（GCC Low-Level Runtime Library）

-lgcc 是 GCC 编译器的运行时支持库。它包含了一些 GCC 编译器生成代码时所需要的底层函数。例如，它提供了整数除法、浮点运算等基本功能，这些功能在硬件没有直接支持时需要通过软件实现。

在操作系统中的角色

在操作系统环境下，-lgcc 负责提供一些基本的低级函数，但通常与标准 C 库和操作系统密切结合。例如，如果编译器生成的代码需要除法操作而目标处理器不支持直接的硬件除法指令，-lgcc 中的函数将为其提供支持。

在裸机编程中的问题

在裸机编程环境中，如果尝试链接 -lgcc 而没有提供必要的底层支持库或编译器的完整配置，可能会遇到链接器错误。虽然 -lgcc 作为底层库通常可以用于裸机环境，但其功能必须与裸机的需求相匹配。如果编译器配置不完整或者工具链不支持裸机环境，可能导致找不到 -lgcc，从而报错。

裸机程序通常不依赖于完整的 GCC 运行时支持库，尤其是在编译器已经生成适合裸机的代码时。你可以手动实现一些关键的低级功能，例如通过直接使用硬件指令来进行除法或者浮点数运算，而不是依赖 -lgcc 提供的这些函数。

总的来说

• 裸机程序必须手动提供启动代码和运行时支持。这意味着程序员需要实现类似 crt0.o 的功能（如栈指针设置、全局变量初始化等），而不是依赖 C 运行时环境。
• 裸机程序通常不会使用完整的 C 标准库，而是使用特定的库或者直接操作硬件来实现必要的功能。

启动代码（Startup Code）的作用

1. 硬件初始化：在没有操作系统的情况下，必须手动初始化硬件资源，例如设置堆栈指针（sp），初始化 .bss 段（存储未初始化的全局和静态变量），设置时钟等硬件外设。
2. 程序入口设置：启动代码提供了程序的入口点，通常是 _start，它是裸机程序的执行起点。启动代码会调用 main 函数，使 C 代码能够开始执行。
3. 防止程序异常返回：在裸机程序中，没有操作系统来接管程序退出后的行为。启动代码通常在 main 函数结束后进入无限循环，避免程序运行到未定义区域。

下面，为了在裸机环境下成功编译，必须告诉链接器不要使用默认的 C 运行时启动文件（crt0.o）和标准库（libc）。你可以通过以下步骤解决这个问题：

修改编译命令

你需要通过 -nostartfiles 和 -nostdlib 告诉编译器不要链接标准启动文件和库。

使用如下的命令编译：

riscv64-unknown-elf-gcc -g -nostartfiles -nostdlib -o hello.elf hello.c

• -nostartfiles：不使用默认的 C 运行时启动文件（如 crt0.o）。
• -nostdlib：不链接标准库（如 libc 和 libgloss）。

手动指定启动文件

在裸机编程中，你需要手动提供启动代码（startup），通常这被称为启动汇编文件 crt0.s 或类似文件，负责设置堆栈指针、清理 bss 段等。你可以编写一个简单的启动代码来解决这个问题。

这里是一个简单的裸机 RISC-V 启动文件 start.s：

# start.s
.globl _start
_start:
    # 设置堆栈指针 (sp)
    la sp, _stack_top

    # 跳转到 main 函数
    call main

    # 无限循环，防止返回
    1: j 1b

这个文件设置了堆栈指针并跳转到 main 函数。

这个汇编代码（start.s）讲解

1. .globl _start

.globl _start

• 作用：这是一个汇编伪指令，定义符号 _start 为全局符号，使其可以在链接器阶段被其他文件（如链接器脚本或编译器）引用。全局符号的作用是告诉链接器，程序的入口点在这个标签 _start。

• 程序入口：在裸机编程中，程序不会像在操作系统环境中那样自动找到 main 函数作为入口。取而代之的是程序从 _start 标签开始执行。链接器脚本中的 ENTRY(_start) 就指定程序从这个标签开始执行。

2. _start:

_start:

• 标签：这是一个汇编标签，表示代码执行的起始位置。这里的 _start 就是程序的入口点，程序执行从这里开始。通过链接器脚本将 _start 设置为程序入口，机器在复位后或上电启动后会从这里开始执行指令。

3. 设置堆栈指针（la sp, _stack_top）

la sp, _stack_top

• 解释：la 是 load address 的缩写，它的作用是将 _stack_top 的地址加载到 sp 寄存器中。sp 寄存器是 RISC-V 架构中存放堆栈指针（stack pointer）的寄存器。

• 作用：程序运行时，堆栈（stack）用于存储函数调用时的返回地址、局部变量、保存寄存器状态等。sp 寄存器指向堆栈的栈顶。这里将 _stack_top 的地址设置为栈顶地址，表示从该地址开始向下增长存储数据。

  堆栈通常向低地址方向增长，因此 _stack_top 设置为某个高地址位置，以确保堆栈有足够的空间来存储数据。

• 裸机编程中的作用：在操作系统中，堆栈指针通常由操作系统设置，但在裸机编程中，开发者必须手动设置堆栈指针。在没有操作系统的环境中，这一行代码确保函数调用和局部变量可以正常使用堆栈。

4. 跳转到 main 函数

call main

• 解释：call 是 RISC-V 的调用指令，它的作用是跳转到指定函数的地址并保存当前的返回地址。

• 作用：这里通过 call main 跳转到 C 语言中定义的 main 函数。此时，C 语言代码的执行开始，main 函数通常包含程序的主要逻辑。

• call 指令细节：

  • 跳转到 main 函数。
  • 将当前指令地址（即 _start 位置）保存到 ra 寄存器（返回地址寄存器），以便 main 函数执行完成后能够返回。

• 裸机编程中的返回问题：在操作系统环境中，main 函数返回后，系统会自动清理程序并退出。但在裸机编程中，没有操作系统管理返回点。如果 main 函数执行完毕，裸机程序无法返回到有效的地址（因为没有操作系统接管程序），这会导致未定义的行为。因此，通常在启动代码中会防止程序返回。

5. 无限循环（1: j 1b）

1: j 1b

• 解释：

  • 1: 是一个标签，用于标识代码中的位置。
  • j 1b 是一个跳转指令，1b 表示向上跳转到标签 1，即再次跳转到 1: 的位置，形成一个无限循环。

• 作用：这一行代码确保程序在 main 函数返回后不会继续执行到未知区域。如果没有这行代码，程序可能会继续运行到未定义的内存区域，引发错误或系统崩溃。

• 裸机程序中的必要性：裸机程序通常没有明确的退出机制。为了防止程序返回到没有定义的地址区域，常常使用一个无限循环来保证程序停留在安全的已知位置，而不会继续执行未定义的指令。通过这个无限循环，程序会保持执行状态，直到硬件系统被复位或重启。

重新编译

在当前目录下添加start.s启动文件后，将启动文件与程序一起编译：

riscv64-unknown-elf-gcc -g -nostartfiles -nostdlib -o hello.elf start.s hello.c

报错3：又报错了 你是不是故意的 😠

五、使用链接脚本

上面的错误提示说明了一个很明显的问题，我们之前在启动文件 start.s中使用的 _stack_top 这个符号没有定义。_stack_top 通常是用来表示堆栈顶的地址，而这个地址需要在链接脚本中定义或在程序中指定。

链接脚本（Linker Script）的作用

1. 内存布局控制：链接脚本负责将程序的各个部分（代码段、数据段、堆栈等）分配到正确的内存地址。裸机程序无法依赖操作系统分配内存，所以必须通过链接脚本手动指定程序的内存布局。
2. 定义程序入口：链接脚本告诉编译器和链接器程序的入口点，例如 _start。这样编译器能够正确识别启动代码的位置。
3. 控制段的布局：链接脚本控制 .text（代码段）、.data（初始化数据段）、.bss（未初始化数据段）等段在内存中的位置，确保它们不互相重叠并且正确对齐，以便裸机程序正常运行。

启动代码、链接脚本与编译器和链接器

启动代码、链接脚本与编译器和链接器紧密关联，它们在程序的编译、链接以及执行过程中各自承担不同的职责，共同确保裸机程序可以正确运行。

1. 编译器的角色

编译器（如 gcc、clang）的主要任务是将高级语言（如 C、C++）代码编译成汇编代码或机器码。这个过程中，编译器只负责将单个源文件翻译成目标文件（.o 文件），但编译器并不知道程序的入口点、内存布局等系统级信息。编译器的作用可以分为以下几步：

• 编译 C 代码：将 C 文件（如 main.c）转换成目标文件（.o 文件），这个文件只包含机器码，并未包含程序如何加载和执行的信息。
• 引入汇编代码：编译器也可以将汇编文件（如 start.s）编译为目标文件，这个文件通常包含程序的启动逻辑，如设置堆栈指针、调用 main 函数等。

2. 启动代码与编译器的关系

启动代码（通常是汇编文件，如 start.s）告诉编译器程序从哪里开始执行，如何初始化环境。它作为一个源文件由编译器处理，将其转换为目标文件。

启动代码与编译器的关系：

• 启动代码提供程序的入口点，例如 _start。这个入口点是编译器需要知道的，用于将机器指令汇编成目标文件。
• 启动代码中设置的堆栈指针（sp）、全局变量初始化等都是程序开始执行时的必要步骤，编译器生成的目标文件依赖于这些初始化操作。

3. 链接器的角色

链接器（如 ld）的任务是将多个目标文件（编译器生成的 .o 文件）合并成一个最终的可执行文件（如 .elf 文件），并解决所有符号引用。链接器的职责包括：

• 符号解析：链接器将不同目标文件中的符号（如函数名、变量名）进行解析和匹配，确保函数调用和数据访问都指向正确的地址。
• 内存布局控制：链接器根据链接脚本提供的指令，将代码段、数据段等放置到正确的内存地址。

4. 链接脚本与链接器的关系

链接脚本（如 linker.ld）为链接器提供程序的内存布局信息，它指定了程序各个段（.text、.data、.bss 等）在内存中的具体位置，以及程序入口点。

链接脚本与链接器的关系：

• 内存布局控制：链接脚本告诉链接器如何将程序的各个部分（如代码段、数据段）映射到目标机器的物理内存地址。例如，指定 .text 段从内存的 0x10000 开始。
• 入口点设置：链接脚本通常指定程序的入口点，例如 ENTRY(_start)，告诉链接器在生成最终的可执行文件时，将程序从 _start 开始执行。
• 符号定义：链接脚本可以定义一些特殊符号，如栈顶（_stack_top）的位置，供启动代码和链接器使用，确保正确的运行时环境。

5. 启动代码、链接脚本与编译器和链接器的整体关系

1. 编译器阶段：

   • 编译器将 C 代码和汇编代码分别编译成目标文件（.o 文件），其中启动代码的汇编文件提供了程序的入口点（_start）以及堆栈指针的初始化。
   • 编译器生成的目标文件中并没有绝对的地址，它只包含相对地址和未解析的符号（如 main 函数的地址）。

2. 链接器阶段：

   • 链接器接收多个目标文件（如 start.o 和 main.o），根据链接脚本中的指令，将代码段、数据段等放置到合适的内存位置，并解析所有未定义的符号。
   • 链接脚本告诉链接器程序的入口点、各个段的布局（如 .text、.data、.bss 等），并设置堆栈位置等特殊符号。
   • 链接器最后生成一个可执行文件（如 hello.elf），这个文件包含了裸机程序的完整布局和所有已解析的符号。

3. 程序运行时：

   • 程序从启动代码（_start）开始执行，启动代码根据链接脚本定义的堆栈顶地址（_stack_top）设置堆栈指针，然后跳转到 main 函数。
   • 在没有操作系统的环境下，启动代码还负责初始化全局变量（如 .data 段）、清零 .bss 段等。

使用链接脚本

在裸机环境下，堆栈和其他内存区域的地址通常是在链接脚本（linker script）中定义的。为了解决错误，你可以编写一个简单的链接脚本，手动定义堆栈顶的地址。

1. 编写一个简单的链接脚本，如 linker.ld：

/* linker.ld */
OUTPUT_ARCH(riscv)
ENTRY(_start)   /* 设置入口点为 _start */

SECTIONS
{
    . = 0x80000000; /* 指定代码起始地址，假设放在 0x80000000 处 */

    .text : {
        *(.text)   /* 将所有 .text 段放在 .text 区 */
    }

    .rodata : {
        *(.rodata) /* 将只读数据段放在 .rodata 区 */
    }

    .data : {
        *(.data)   /* 将 .data 段放在 .data 区 */
    }

    .bss : {
        *(.bss)    /* 将 .bss 段放在 .bss 区 */
    }

    _stack_top = 0x80010000;  /* 定义堆栈顶的地址 */
}

这里将堆栈顶定义为 0x80010000（这个地址可以根据你的需求调整）。

在汇编文件中定义 _stack_top

我们需要在启动代码中，添加 _stack_top的地址：

s

添加链接脚本linker.ld和修改启动代码start.s后，重新编译：

riscv64-unknown-elf-gcc -g -nostartfiles -nostdlib -T linker.ld -o hello.elf start.s hello.c

不用说肯定还得报错😊，甚至紧跟着两个报错

另外提前说一下，如果 QEMU 卡住了，你可以通过【 Ctrl + A，然后按 X 】退出。

六、修复报错，启动QEMU

报错4

这个问题通过添加使用 -mcmodel=medany选项解决。

这个问题不用深究，未来的 rust 裸机编程没有这个问题。

如果你想了解更多，参见The RISC-V Code Models / RISC-V Options。

简单来说，RISC-V 有不同的代码模型（Code Model）来决定如何处理内存地址的范围：

1. medlow（默认）：
   • 假设所有全局数据和代码的地址都在低于 2GB 的范围内，通常是从基地址 0 开始。
   • 这种模型只适用于小型程序，因为它限制了可访问的内存范围。
2. medany：
   • 允许全局数据和代码放置在内存中的任意位置（中高位置），不局限于低 2GB 地址空间。
   • 这个模型使用了更多的指令来确保数据和代码的地址可以被访问，而不受限制。

重新编译：

riscv64-unknown-elf-gcc -g -nostartfiles -nostdlib -T linker.ld -mcmodel=medany -o hello.elf start.s hello.c

成功了！

接下来是，使用 QEMU 来模拟 RISC-V 环境并运行刚刚编译的 hello 程序。命令如下：

qemu-system-riscv64 -machine virt -nographic -kernel hello.elf -s -S

• -machine virt：选择 QEMU 中的虚拟 RISC-V 机器。
• -nographic：表示不使用图形界面，所有输出通过当前终端处理。
• -kernel hello：指定要加载并运行的 RISC-V 程序。
• -s：启用调试模式，会在端口 1234 上开启一个 GDB 服务器。
• -S：告诉 QEMU 在启动后暂停 CPU，这样我们可以连接 GDB 进行调试，而不会立即运行程序。

不出意外的话，QEMU 会启动，但处于暂停状态，等待 GDB 连接。

出意外的话。。

报错5

从错误信息来看， hello.elf 程序和 QEMU 默认加载的 OpenSBI 固件的地址发生了冲突。OpenSBI 固件被加载到 0x80000000 地址空间，而 hello.elf 程序的代码段也从 0x80000000 开始，这导致了地址重叠问题。

解决方案

1. 使用 -bios none 禁用 OpenSBI 固件

如果当前的程序不需要依赖 OpenSBI 提供的服务（例如打印字符等），可以通过-bios none禁用 QEMU 默认加载的 OpenSBI 固件来避免冲突：

qemu-system-riscv64 -machine virt -nographic -bios none -kernel hello.elf -s -S

这个命令会让 QEMU 不加载任何 BIOS 或 OpenSBI 固件，而直接运行你自己的 hello.elf 程序。

2. 更改程序加载地址

显然我们还需要 OpenSBI 的功能，那么可以将 hello.elf 程序加载到不同的内存地址，避免和 OpenSBI 地址重叠。默认情况下，OpenSBI 固件从 0x80000000 地址加载，我们可以在 linker.ld 文件中设置不同的加载地址。例如，你可以把加载地址设置为 0x80200000 或者更高：

/* linker.ld */
OUTPUT_ARCH(riscv)
ENTRY(_start)

SECTIONS
{
    . = 0x80200000;  /* 将代码段起始地址设置为 0x80200000，避免和 OpenSBI 地址冲突 */

    .text : {
        *(.text)     /* 将所有的 .text 段放在 .text 区 */
    }

    .rodata : {
        *(.rodata)   /* 将只读数据放在 .rodata 区 */
    }

    .data : {
        *(.data)     /* 将 .data 段放在 .data 区 */
    }

    .bss : {
        *(.bss)      /* 将 .bss 段放在 .bss 区 */
    }

    _stack_top = 0x80400000;  /* 定义堆栈顶的地址为更高的地址 */
}

这样，程序就会被加载到 0x80200000 以避免与 OpenSBI 地址重叠。

3. 指定 OpenSBI 固件

你也可以使用 -bios 选项指定一个 OpenSBI 固件，并让 QEMU加载你的程序和 OpenSBI。比如你下载了一个 OpenSBI 固件 opensbi.elf，可以使用以下命令运行：

qemu-system-riscv64 -machine virt -nographic -bios /path/to/opensbi.elf -kernel hello.elf -s -S

这个以后再说。

总之我们选择了让程序为 OpenSBI 让路，把加载地址设置为 0x80200000，同时start.s 文件中的栈指针设置也应该根据新的加载地址进行调整。

更新后的 start.s 文件

.globl _start
_start:
    # 设置堆栈指针 (sp)，将其设置在 0x80400000 位置（比代码地址更高）
    la sp, _stack_top

    # 跳转到 main 函数
    call main

    # 无限循环，避免程序退出
1:  j 1b

.globl _stack_top
_stack_top:
    .word 0x80400000  # 将栈顶设置在 0x80400000 位置（高于代码加载区域）

更新完文件后再次运行QEMU：

qemu-system-riscv64 -machine virt -nographic -kernel hello.elf -s -S

怎么没反应啊，不会还有bug吧？

当你看到只剩下闪动的光标，别担心，恭喜你已经完成了QEMU的启动🎉，正如前面参数介绍的那样：

• -machine virt：选择 QEMU 中的虚拟 RISC-V 机器。
• -nographic：表示不使用图形界面，所有输出通过当前终端处理。
• -kernel hello：指定要加载并运行的 RISC-V 程序。
• -s：启用调试模式，会在端口 1234 上开启一个 GDB 服务器。
• -S：告诉 QEMU 在启动后暂停 CPU，这样我们可以连接 GDB 进行调试，而不会立即运行程序。

QEMU 已经启动，但处于暂停状态，正在等待 GDB 连接。

七、连接 GDB 进行调试

接下来的步骤是连接 GDB 进行调试。

简要步骤

1. 打开一个新的终端：在新终端中，确保你的程序已经编译并准备好运行。

2. 启动 GDB：使用 GDB 加载你的程序。例如，如果你的程序名为 hello，输入以下命令：

   riscv64-unknown-elf-gdb hello.elf
   

   

3. 连接到 QEMU：在 GDB 提示符下，输入以下命令连接到 QEMU 的 GDB 服务器（连接成功后就和上一节类似啦）：

   target remote :1234
   

   

4. 设置断点（可选）：如果你想在程序的某个位置停止执行，可以设置断点，例如：

   break main
   

5. 开始执行程序：输入以下命令开始程序的执行（到断点）：

   continue
   

6. 调试程序：在程序运行时，你可以使用 GDB 的各种命令来查看寄存器状态、内存内容等。

7. 退出 GDB：完成调试后，可以使用以下命令退出 GDB：

   quit
   

调试细节步骤

连接成功后break main在 main 函数入口处设置断点，

c开始程序执行到断点。

当前屏幕展示了两个窗口，分别是调试窗口（左侧）和 QEMU 界面（右侧）。

左侧 - GDB 调试界面

• 调试工具：这是你使用 riscv64-unknown-elf-gdb 启动的调试会话。你已成功连接到运行在 QEMU 上的 RISC-V 模拟器。
• 断点信息：
  • 在 main 函数入口处设置了一个断点，这一行调用了 print_string("Hello, World! x10 (fake)\n");。
  • 当前 GDB 已经在这个断点停住，命中了一次，即程序执行到这一行时被暂停。
• 汇编指令窗口：
  • 显示了当前程序执行位置周围的 RISC-V 汇编指令。
  • 可以看到 GDB 解释的指令，如 addi、auipc、jal 等，这些是编译后的程序的实际指令，正在被 QEMU 模拟器执行。
• 寄存器信息：
  • 当前寄存器的状态已经显示在调试界面的左下角部分。
  • 可以看到 sp、ra、a0 等寄存器的当前值，表明程序的执行状态。
• 源码窗口：
  • 可以看到 C 源码的当前执行位置，print_string("Hello, World! x10 (fake)\n"); 正在等待被执行。
  • 下方有一个无限循环 while(1)，目的是防止程序退出，让程序一直运行。

右侧 - QEMU 界面

• QEMU 启动输出：
  • QEMU 模拟器已经启动，并加载了 OpenSBI（Supervisor Binary Interface），用于在 QEMU 虚拟机上管理硬件抽象。
  • 右侧窗口显示的是 OpenSBI 启动时的输出信息：
    • OpenSBI 的版本为 0.3。
    • 平台名称为 riscv-virtio,qemu，即 QEMU 使用的 RISC-V 虚拟平台。
    • 列出了平台的各种设备信息，例如定时器、IPT（中断控制）设备和 UART 控制台设备。
• 暂停状态：
  • 由于 QEMU 启动时使用了 -S 参数，模拟器启动后暂停了 CPU 的执行。当前，QEMU 处于等待状态，没有执行加载的程序。
  • 一旦你在 GDB 中发出 continue（或 c）命令，QEMU 会继续执行程序。

s进入print_string

n运行下一条代码，这里我们依旧忽略print_char调用sbi_call以及后续一系列的内部的实现，继续n跳转到第一次执行完print_char函数的位置。

观察QEMU发生了什么：

继续：

{

n进入下一个循环（或者回车自动继续执行上一条指令）

n完成下一次打印

}

直到：

下一步是进入无限循环。

结束。通过【 Ctrl + A，然后按 X 】退出QEMU，通过q退出QEMU。

终于算是暂时结束了 [/躺平]

下一节开始转向 RUST！

等等等等，好像把 Makefile 忘了？

使用rust-gdb调试Rust/标准库println!的实现

一、调试基础 Rust 程序：使用 GDB 调试 Hello, World!

A. 安装和设置 GDB 调试环境

在 Rust 中，调试器 rust-gdb 是基于 GNU 调试器 (GDB) 的一个增强版，专门为 Rust 提供了语言特定的支持，比如对 Rust 类型的更好解析、语法和格式化信息显示。使用 rust-gdb，可以轻松调试 Rust 程序，并查看代码的实际运行过程，包括变量状态和函数调用链等。

安装 rust-gdb：

Rust 工具链中的调试器 rust-gdb 作为一个可选组件，需要通过 rustup 工具安装：

rustup component add rust-gdb

这个命令会将 rust-gdb 安装到当前的 Rust 工具链中。成功安装后，可以直接在终端中运行 rust-gdb 命令来启动调试会话。

系统要求：

rust-gdb 依赖于你系统中已经安装的 GDB，因此请确保系统中有 GDB 并且版本与当前 Rust 工具链兼容。你可以通过以下命令检查 GDB 的版本：

gdb --version

Rust 的调试信息生成是通过 DWARF 格式，因此在调试器中需要确保 GDB 能够识别并使用这些调试信息。

B. 编写并编译简单的 Hello, World! 程序

现在，我们编写一个非常简单的 Rust 程序，并使用 cargo 进行编译。

新建 Rust 项目：

可以使用 cargo 命令创建一个新的项目：

cargo new hello_world_gdb --bin

该命令会在当前目录下创建一个新的二进制项目，项目名为 hello_world_gdb。目录结构如下：

hello_world_gdb/
├── Cargo.toml
└── src/
    └── main.rs

编写 Hello, World! 代码：

进入 src/main.rs 文件，已经包含基础的 Hello, World! 程序：

fn main() {
    println!("Hello, World!");
}