RISC-V on 夜云泊

SCP-firmware 源码分析-module 间 api 调用分析

Thu, 15 Aug 2024 15:42:13 +0800

想了解如何提供 API，我们先看看 CMN 模块是如何使用 API 的，在文件module/cmn700/src/mod_cmn700.c我们可以看到如下代码：

// module/cmn700/src/mod_cmn700.c
static struct mod_system_info_get_info_api *system_info_api;

int cmn700_start(fwk_id_t id)
{
    ...
    status = system_info_api->get_system_info(&system_info);
    if (status == FWK_SUCCESS) {
        chip_id = system_info->chip_id;
        multi_chip_mode = system_info->multi_chip_mode;
    }
    ...
}

他调用了system_info_api->get_system_info这个函数，实际这就是 mod_system_info 暴露给 mod_cmn700 的一个 API。用于获取系统信息。

为何这个静态变量system_info_api就能调用到mod_system_info的函数呢？我们继续搜索代码，可以看到如下代码：

// module/cmn700/src/mod_cmn700.c
static int cmn700_bind(fwk_id_t id, unsigned int round)
{
    ...
    if (fwk_id_is_type(id, FWK_ID_TYPE_MODULE)) {
        /* Bind to system info module to obtain multi-chip info */
        status = fwk_module_bind(
            FWK_ID_MODULE(FWK_MODULE_IDX_SYSTEM_INFO),
            FWK_ID_API(FWK_MODULE_IDX_SYSTEM_INFO, MOD_SYSTEM_INFO_GET_API_IDX),
            &system_info_api);
        return status;
    }
    ...
}

在cmn700_bind函数中，调用了fwk_module_bind函数，这个函数的作用是绑定一个模块的 API，这样就可以通过这个 API 调用模块的函数。fwk_module_bind函数的第一个参数是提供 API 的模块的 ID，比如当前是模块system_info的 ID，如果是要用 USB 的 API，那么就是 USB 模块的 ID。第二个参数是 API 的 ID，这个 ID 是在模块的头文件中定义的，比如mod_system_info.h中定义了MOD_SYSTEM_INFO_GET_API_IDX，这个宏定义的值就是 API 的 ID。第三个参数是 API 的指针，这个指针就是开头提到的静态变量的地址，它是定义在使用 API 的模块中的。这样就可以通过 API 的指针调用模块的函数。对于 USB 模块，我们就需要在使用到 USB 的模块中定义一个静态变量。

fwk_module_bind做了什么呢？进入该函数，可以看到它回调了mod_system_info的process_bind_request函数，也就是system_info_process_bind_request函数。

// framework/src/fwk_module.c
int fwk_module_bind(fwk_id_t target_id, fwk_id_t api_id, const void *api)
{
    ...
    status = fwk_mod_ctx->desc->process_bind_request(
        fwk_module_ctx.bind_id, target_id, api_id, (const void **)api);
    ...
}

system_info_process_bind_request函数的作用是根据 API 的 ID 返回 API 的指针。它把get_system_info_api的地址赋值给了api。这就实现了 API 的暴露。经过这个函数，system_info_api就指向了get_system_info_api。实际就是我们在cmn700_bind函数中使用system_info_api就是在调用get_system_info_api。

// module/system_info/src/mod_system_info.c
static int system_info_process_bind_request(fwk_id_t requester_id,
        fwk_id_t targer_id, fwk_id_t api_id, const void **api)
{
    switch (fwk_id_get_api_idx(api_id)) {
    case MOD_SYSTEM_INFO_GET_API_IDX:
        *api = &get_system_info_api;
        break;
    default:
        return FWK_E_PARAM;
    }
    return FWK_SUCCESS;
}

解释完这个 bind 函数，它是在哪被调用的？它在框架初始化时就会被调用，分析fwk_arch_init函数，可以看到在fwk_module_start函数中会对每一个模块调用bind函数。函数调用流程参考图片文件。在此就不再赘述了。

经过以上分析，提供 API 的模块需要做的事情就是：

在模块的头文件中定义 API 的 ID，它有一定的格式，具体可以参考 MSCP 文档doc/framework.md的APIs章节。
```
enum mod_modulename_api {
    MOD_MODULENAME_API_A,
    MOD_MODULENAME_API_B,
};
```

在模块的源文件中定义 API 结构体，用于在其他模块中使用。

struct mod_system_info_get_info_api {
    int (*get_system_info)(const struct mod_system_info **sys_info);
};

在模块原文件中提供process_bind_request函数，用于根据 API 的 ID 返回 API 的指针。

static int system_info_process_bind_request(fwk_id_t requester_id,
    fwk_id_t targer_id, fwk_id_t api_id, const void **api)
{
    switch (fwk_id_get_api_idx(api_id)) {
    case MOD_SYSTEM_INFO_GET_API_IDX:
        *api = &get_system_info_api;
        break;
    default:
        return FWK_E_PARAM;
    }
    return FWK_SUCCESS;
}

在模块的源文件中定义 API 的指针，用于提供 API 的地址。

static struct mod_system_info_get_info_api get_system_info_api = {
    .get_system_info = system_info_get_system_info,
};

实现需要提供的 API 函数。

static int system_info_get_system_info(const struct mod_system_info **sys_info)
{
    *sys_info = &system_info;
    return FWK_SUCCESS;
}

以上就是大致的移植流程了。

Responsive Image

SCP-firmware 源码分析 - 源码编译以及模块初始化流程

Sat, 10 Aug 2024 15:42:13 +0800

编译源码

下载配置工具链

访问ARM 官网下载工具链下载自己系统的版本的工具链。如果你也是 x86_64 的 Linux 系统，直接点击该链接下载 arm-gnu-toolchain-13.3

解压工具链：

xz -d arm-gnu-toolchain-13.3.rel1-x86_64-aarch64-none-linux-gnu.tar.xz
tar -xvf arm-gnu-toolchain-13.3.rel1-x86_64-aarch64-none-linux-gnu.tar

将工具链路径添加到环境变量中。

编译源码

源码使用 CMake 进行编译，CMake 版本需要 3.18.4 以上。如果你是 Ubuntu 20.04，直接安装即可。

sudo apt install cmake

如果你是 Ubuntu 18.04，需要升级 CMAKE。可以通过下面的方式下载源码编译安装 CMAKE。

wget https://github.com/Kitware/CMake/releases/download/v3.22.0/cmake-3.22.0-linux-x86_64.tar.gz
tar -zxvf cmake-3.22.0-linux-x86_64.tar.gz
mv cmake-3.22.0-linux-x86_64 /usr/local/cmake
export PATH=/usr/local/cmake/bin:$PATH

源码编译：

make -f Makefile.cmake PRODUCT=totalcompute/tc2 MODE=debug firmware-scp_ramfw

源码编译成功后，会在build/tc2/GNU/debug/firmware-scp_ramfw/bin目录下生成二进制文件。具体编译参数，可以参考源码根目录下的user_guide文档。

初始化流程分析

Responsive Image

fwk_module_init 初始时，module_config_table 是在什么时候被初始化的？

module_config_table 无法在源码中直接搜索到，因为它是在编译过程中生成的，当你编译一次后，就会在 output/build/mpw/GNU/debug/firmware-scp_romfw/framework/src/fwk_module_list.c 找到这个变量。具体它是如何生成的，注意通过 framework/CMakeLists.txt 文件中的这段代码完成，我们逐行分析这段代码。

list(LENGTH SCP_MODULES SCP_MODULE_IDX_MAX)

获取模块列表的长度，保存在 SCP_MODULE_IDX_MAX 变量中。在每个 Firmware.cmake 文件中，都会有一个 SCP_MODULES 变量，这个变量保存了该产品所包含的模块。

# product/juno/scp_romfw/Firmware.cmake
list(APPEND SCP_MODULES "test")
list(APPEND SCP_MODULES "uart")

当前我们加入了两个模块，所以 SCP_MODULE_IDX_MAX 的值为 2。

foreach(idx RANGE ${SCP_MODULE_IDX_MAX})
    if(idx EQUAL SCP_MODULE_IDX_MAX)
        string(APPEND SCP_MODULE_IDX_GEN "    FWK_MODULE_IDX_COUNT = ${idx},\n")

        break()
    endif()

遍历模块列表，生成模块索引的定义，如下：

enum fwk_module_idx {
    FWK_MODULE_IDX_COUNT = 0,
};

    list(GET SCP_MODULES ${idx} SCP_MODULE)

将 SCP_MODULES 列表中索引为 idx 的元素赋值给变量 SCP_MODULE，以便在后续的代码中使用。当前 idx 为 0，所以 SCP_MODULE 为 test。

    string(MAKE_C_IDENTIFIER ${SCP_MODULE} SCP_MODULE)
    string(TOUPPER ${SCP_MODULE} SCP_MODULE_UPPER)

将 SCP_MODULE 转换为 C 标识符。将 SCP_MODULE 转为大写并保存在 SCP_MODULE_UPPER 中，即 SCP_MODULE_UPPER="TEST"

    string(APPEND SCP_MODULE_IDX_GEN "    FWK_MODULE_IDX_${SCP_MODULE_UPPER} = ${idx},\n")
    string(APPEND SCP_MODULE_ID_INIT_GEN "#define FWK_MODULE_ID_${SCP_MODULE_UPPER}_INIT FWK_ID_MODULE_INIT(FWK_MODULE_IDX_${SCP_MODULE_UPPER})\n")
    string(APPEND SCP_MODULE_ID_GEN "#define FWK_MODULE_ID_${SCP_MODULE_UPPER} FWK_ID_MODULE(FWK_MODULE_IDX_${SCP_MODULE_UPPER})\n")
    string(APPEND SCP_MODULE_ID_CONST_GEN "static const fwk_id_t fwk_module_id_${SCP_MODULE} = FWK_MODULE_ID_${SCP_MODULE_UPPER}_INIT;\n")
    string(APPEND SCP_MODULE_EXTERN_GEN "extern const struct fwk_module module_${SCP_MODULE};\n")
    string(APPEND SCP_MODULE_EXTERN_CONFIG_GEN "extern const struct fwk_module_config config_${SCP_MODULE};\n")
    string(APPEND SCP_MODULE_GEN "    &module_${SCP_MODULE},\n")
    string(APPEND SCP_MODULE_CONFIG_GEN "    &config_${SCP_MODULE},\n")

进行一些宏替换，替换后的结果如下：

SCP_MODULE_IDX_GEN: "   FWK_MODULE_IDX_TEST = 0,"
SCP_MODULE_ID_INIT_GEN: "#define FWK_MODULE_ID_TEST_INIT FWK_ID_MODULE_INIT(FWK_MODULE_IDX_TEST)"
SCP_MODULE_ID_GEN: "#define FWK_MODULE_ID_TEST FWK_ID_MODULE(FWK_MODULE_IDX_TEST)"
SCP_MODULE_ID_CONST_GEN: "static const fwk_id_t fwk_module_id_test = FWK_MODULE_ID_TEST_INIT;"
SCP_MODULE_EXTERN_GEN: "extern const struct fwk_module module_test;"
SCP_MODULE_EXTERN_CONFIG_GEN: "extern const struct fwk_module_config config_test;"
SCP_MODULE_GEN: "&module_test,"
SCP_MODULE_CONFIG_GEN: "&config_test,"

    target_compile_definitions(framework
                               PUBLIC "BUILD_HAS_MOD_${SCP_MODULE_UPPER}=1")

将 BUILD_HAS_MOD_TEST 定义为 1，以便在后续的代码中使用。

在源码文件中有两个模板文件，分别为 fwk_module_list.c.in 和 fwk_module_idx.h.in，这两个文件中包含了一些宏定义，这些宏定义在编译过程中会被替换为上面生成的宏定义。

#include <stddef.h>

@SCP_MODULE_EXTERN_GEN@

const struct fwk_module *module_table[FWK_MODULE_IDX_COUNT] = {
@SCP_MODULE_GEN@
};

@SCP_MODULE_EXTERN_CONFIG_GEN@

const struct fwk_module_config *module_config_table[FWK_MODULE_IDX_COUNT] = {
@SCP_MODULE_CONFIG_GEN@
};

#include <fwk_id.h>

@SCP_MODULE_ID_INIT_GEN@
@SCP_MODULE_ID_GEN@

enum fwk_module_idx {
@SCP_MODULE_IDX_GEN@
};

@SCP_MODULE_ID_CONST_GEN@

在编译过程中就会生成下面两个文件，当使用module_config_table时，就会引用这两个文件，找到对应的配置。

// build/mpw/GNU/debug/firmware-scp_romfw/framework/include/fwk_module_idx.h
#define FWK_MODULE_ID_TEST_INIT FWK_ID_MODULE_INIT(FWK_MODULE_IDX_TEST)
#define FWK_MODULE_ID_UART_INIT FWK_ID_MODULE_INIT(FWK_MODULE_IDX_UART)


#define FWK_MODULE_ID_TEST FWK_ID_MODULE(FWK_MODULE_IDX_TEST)
#define FWK_MODULE_ID_UART FWK_ID_MODULE(FWK_MODULE_IDX_UART)


enum fwk_module_idx {
    FWK_MODULE_IDX_TEST = 0,
    FWK_MODULE_IDX_UART = 1,
    FWK_MODULE_IDX_COUNT = 2,

};

static const fwk_id_t fwk_module_id_test = FWK_MODULE_ID_TEST_INIT;
static const fwk_id_t fwk_module_id_uart = FWK_MODULE_ID_UART_INIT;

// build/mpw/GNU/debug/firmware-scp_romfw/framework/src/fwk_module_list.c
extern const struct fwk_module module_test;
extern const struct fwk_module module_uart;


const struct fwk_module *module_table[FWK_MODULE_IDX_COUNT] = {
    &module_test,
    &module_uart,

};

extern const struct fwk_module_config config_test;
extern const struct fwk_module_config config_uart;


const struct fwk_module_config *module_config_table[FWK_MODULE_IDX_COUNT] = {
    &config_test,
    &config_uart,
};

如何确定各个模块在初始化过程中的执行顺序？

在每个产品目录 mscp/product/juno/scp_romfw/Firmware.cmake 中，都会有一个 Firmware.cmake 文件，这个文件中会包含该产品所包含的模块：

list(APPEND SCP_MODULES "juno-ppu")
list(APPEND SCP_MODULES "juno-rom")
list(APPEND SCP_MODULES "gtimer")
list(APPEND SCP_MODULES "sds")
list(APPEND SCP_MODULES "bootloader")
list(APPEND SCP_MODULES "juno-soc-clock")

编译后会在 output 文件夹中生成fwk_module_idx.h文件，这个文件中会包含所有模块的索引，如下：

Responsive Image

BusyBox 构建并启动 RISC-V Linux 内核

Thu, 20 Jun 2024 21:10:49 +0000

根文件系统

文件系统与根文件系统

文件系统（File System）是操作系统用于管理和存储数据的一种方式。它定义了如何在存储设备（如硬盘、SSD、USB 驱动器等）上组织文件和目录，以及如何进行数据的读写操作。

常见的文件系统类型有：

ext4：Linux 最常用的文件系统，支持大文件和大分区。
NTFS：Windows 操作系统常用的文件系统，支持文件加密和权限控制。
FAT32：一种兼容性广泛的文件系统，常用于 USB 驱动器和内存卡。
XFS：适用于高性能和高容量存储需求的文件系统。
btrfs：一种现代 Linux 文件系统，支持快照、压缩和多设备管理。

根文件系统（Root File System，通常简称为 rootfs）是文件系统层次结构中的顶级文件系统。它包含了操作系统启动和运行所需的所有基本文件和目录。根文件系统是整个文件系统层次的起点，在 Linux 中由单个斜杠（/）表示。根文件系统首先是内核启动时所 mount 的第一个文件系统，内核代码映像文件保存在根文件系统中，而系统引导启动程序会在根文件系统挂载之后从中把一些基本的初始化脚本和服务等加载到内存中去运行。

根文件系统是建立在文件系统之上的。根文件系统使用某种具体的文件系统类型（如 ext4）来管理和存储其内容。

基于内存的文件系统

ramdisk 是一种基于内存的文件系统，它将内存的一部分用作硬盘驱动器，这样就可以在内存中创建一个文件系统。ramdisk 是一个虚拟磁盘，它的大小和硬盘驱动器的大小一样。ramdisk 的优点是速度快，缺点是断电后数据丢失。

根文件系统中各种配置文件的作用以及配置文件的格式介绍

/etc/inittab

/etc/inittab 是 Linux 系统中的一个配置文件，它是 init 程序的配置文件，用于配置系统的运行级别和 init 程序的行为。在 Linux 系统中，init 程序是系统的第一个进程，它负责启动系统中的所有其他进程。/etc/inittab 文件中的每一行都是一个配置项，每个配置项由四个字段组成，字段之间用空格或制表符分隔。/etc/inittab 文件的格式如下：

id:runlevels:action:process

每个字段用冒号分隔，可以缺省。各字段的含义如下：

id：配置项的标识符，用于标识配置项。
runlevels：配置项所对应的运行级别，可以是一个或多个运行级别的组合。
action：配置项的动作，可以是以下几种动作之一：
- sysinit：系统初始化时运行。
- respawn：如果进程终止，立即重新启动。
- askfirst：在运行 process 之前询问用户。并在控制台上显示 Please press Enter to active this console。
- wait：等待进程终止，然后继续执行下一个配置项。
- once：只运行一次，进程终止后不会重新启动。
- boot：在系统引导时运行。
- bootwait：在系统引导时运行，等待进程终止后继续引导。
- initdefault：设置默认运行级别。
- shutdown：在系统关机时运行。
process：要执行的进程或脚本的路径。

示例：

# /etc/inittab
#系统开机或重新启动，执行rcS文件
::sysinit:/etc/init.d/rcS
#系统启动后，运行登录程序  
::askfirst:-/bin/login
#按下组合键“ctrl+alt+del”，重启Linux系统
::ctrlaltdel:-/sbin/reboot   
#系统关机时，卸载所有文件系统
::shutdown:/bin/umount -a -r
#重启init进程
::restart:/sbin/init

/etc/fstab

/etc/fstab 是 Linux 系统中的一个配置文件，用于配置文件系统的挂载信息。在 Linux 系统中，文件系统是通过挂载的方式来访问的，/etc/fstab 文件中记录了系统中所有文件系统的挂载信息。/etc/fstab 文件的格式如下：

device mount_point fs_type options dump pass

各字段的含义如下：

device：设备文件或 UUID。
mount_point：挂载点。
fs_type：文件系统类型。
options：挂载选项。
dump：备份标志，用于备份工具。
pass：文件系统检查顺序。

示例：

# /etc/fstab
# <文件系统>  <挂载点>  <类型>  <选项>        <dump>  <fsck>

# 根文件系统
/dev/sda1       /           ext4    defaults        1       1  # 根分区，使用 ext4 文件系统，默认挂载选项

# /boot 分区，用于存放引导加载程序和内核镜像
/dev/sda2       /boot       ext4    defaults        1       2  # /boot 分区，使用 ext4 文件系统，默认挂载选项

# 交换分区，用作虚拟内存
/dev/sda3       none        swap    sw              0       0  # 交换分区，不需要挂载点，使用 swap 类型

# /home 分区，用于存放用户的个人数据
/dev/sda4       /home       ext4    defaults        1       2  # /home 分区，使用 ext4 文件系统，默认挂载选项

# /tmp 分区，用于存放临时文件
/dev/sda5       /tmp        ext4    defaults        1       2  # /tmp 分区，使用 ext4 文件系统，默认挂载选项

# /var 分区，用于存放可变数据文件，如日志、邮件、缓存等
/dev/sda6       /var        ext4    defaults        1       2  # /var 分区，使用 ext4 文件系统，默认挂载选项

# /mnt/data 分区，用于存放额外的数据文件
/dev/sda7       /mnt/data   ext4    defaults        1       2  # /mnt/data 分区，使用 ext4 文件系统，默认挂载选项

# 挂载 proc 文件系统，用于访问进程和系统信息
proc            /proc       proc    defaults        0       0  # proc 虚拟文件系统，默认挂载选项

# 挂载 sysfs 文件系统，用于访问设备和内核信息
sysfs           /sys        sysfs   defaults        0       0  # sysfs 虚拟文件系统，默认挂载选项

# 挂载 tmpfs 文件系统，用于临时文件存储
tmpfs           /dev/shm    tmpfs   defaults        0       0  # tmpfs 虚拟文件系统，默认挂载选项

# 挂载 devpts 文件系统，用于伪终端设备
devpts          /dev/pts    devpts  gid=5,mode=620  0       0  # devpts 虚拟文件系统，默认挂载选项

/etc/init.d/rcS

/etc/init.d/rcS 是 Linux 系统中的一个初始化脚本，用于系统初始化时运行。在 Linux 系统中，/etc/init.d/rcS 脚本是系统初始化时运行的第一个脚本，它负责初始化系统中的各种服务和配置。/etc/init.d/rcS 脚本通常包含了一些初始化命令，如加载模块、挂载文件系统、启动服务等。/etc/init.d/rcS 脚本的格式如下：

#!/bin/sh
# 这行是 shebang，用于指定这个脚本将由 /bin/sh 解释执行

# 挂载 proc 文件系统到 /proc 目录
mount -t proc none /proc
# proc 文件系统是一个虚拟文件系统，用于提供内核和进程的信息

# 挂载 sysfs 文件系统到 /sys 目录
mount -t sysfs none /sys
# sysfs 文件系统是一个虚拟文件系统，用于提供设备和内核信息

# 挂载 devtmpfs 文件系统到 /dev 目录
mount -t devtmpfs none /dev
# devtmpfs 是一个用于设备节点的临时文件系统

# 运行 mdev 以创建设备节点
/sbin/mdev -s
# mdev 是一个轻量级的设备管理工具，用于创建和管理 /dev 目录中的设备节点

# 设置主机名
echo "myhostname" > /proc/sys/kernel/hostname
# 将主机名设置为 "myhostname"，这个名字可以根据需要更改

# 启动网络接口配置脚本
ifconfig lo up
# 启动回环接口 lo，这是一个特殊的网络接口，用于网络软件本地通信

# 运行所有位于 /etc/init.d/ 目录中的初始化脚本
for script in /etc/init.d/S*; do
  if [ -x "$script" ]; then
    "$script" start
  fi
done
# 遍历 /etc/init.d/ 目录中的所有以 S 开头的脚本，并执行它们以启动相应的服务
# -x 选项用于检查文件是否可执行

# 挂载用户文件系统（可选，根据实际需要）
mount -a
# 挂载 /etc/fstab 文件中列出的所有文件系统

# 打印启动完成信息
echo "System initialization complete."
# 输出系统初始化完成信息

/etc/profile

/etc/profile 是 Linux 系统中的一个全局配置文件，用于配置系统的环境变量和用户的 shell 环境。在 Linux 系统中，/etc/profile 文件是系统启动时加载的第一个配置文件，它包含了系统的全局环境变量和用户的 shell 环境配置。/etc/profile 文件的格式如下：

# /etc/profile
#!/bin/sh
# 这行是 shebang，用于指定这个脚本将由 /bin/sh 解释执行

# 设置 PATH 环境变量，定义系统命令的搜索路径
PATH="/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin"
export PATH
# /usr/local/sbin:/usr/local/bin 是系统管理员和用户安装的程序路径
# /sbin:/bin:/usr/sbin:/usr/bin 是系统默认的命令路径

# 设置用户 umask，定义新文件和目录的默认权限掩码
umask 022
# umask 022 表示新文件的默认权限是 755，新目录的默认权限是 644

# 设置系统语言和区域
LANG="en_US.UTF-8"
export LANG
# LANG 变量定义了系统的语言环境，这里设置为美国英语 UTF-8 编码

# 设置历史记录文件和大小
HISTSIZE=1000
HISTFILESIZE=2000
export HISTSIZE HISTFILESIZE
# HISTSIZE 定义了 shell 会话历史记录的条目数，HISTFILESIZE 定义了历史记录文件的最大条目数

# 系统启动信息
echo "Welcome to your Linux system!"
# 在用户登录时显示欢迎信息

# 读取并执行 /etc/bashrc（如果存在）
if [ -f /etc/bashrc ]; then
    . /etc/bashrc
fi
# /etc/bashrc 是另一个全局配置文件，通常包含 bash shell 的配置
# 使用 . /etc/bashrc 命令将其内容导入当前 shell 环境

# 配置别名（示例）
alias ll='ls -l'
alias la='ls -A'
alias l='ls -CF'
# 定义一些常用命令的别名
# ll 代表 ls -l，显示详细列表
# la 代表 ls -A，显示所有文件包括隐藏文件（但不包括 . 和 ..）
# l 代表 ls -CF，以分类格式显示文件

# 读取用户特定的配置文件（如果存在）
if [ -f "$HOME/.profile" ]; then
    . "$HOME/.profile"
fi
# .profile 是用户的个人配置文件
# 使用 . $HOME/.profile 命令将其内容导入当前 shell 环境

# 设置编辑器
EDITOR=vim
export EDITOR
# 定义默认的文本编辑器为 vim

# 设置主机名显示，也就是终端最前面提示符的样式
PS1='\u@\h:\w\$ '
export PS1
# PS1 定义了 shell 提示符的样式
# \u 代表用户名
# \h 代表主机名
# \w 代表当前工作目录

Busybox 简介以及如何制作 Busybox 文件系统

准备 QEMU

cd && mkdir -p /home/user/program/riscv64-qemu
cd workspace
git clone https://github.com/qemu/qemu.git
cd qemu
cd qemu && ./configure --target-list=riscv32-softmmu,riscv32-linux-user,riscv64-linux-user,riscv64-softmmu \
               --enable-kvm --enable-sdl \
               --prefix=/home/user/program/riscv64-qemu
make install -j $(nproc)

准备 OpenSBI

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

准备 Linux 内核

cd workspace
git clone https://github.com/torvalds/linux.git
make ARCH=riscv CROSS_COMPILE=riscv64-unknown-linux-gnu- defconfig
make ARCH=riscv CROSS_COMPILE=riscv64-unknown-linux-gnu- -j $(nproc)

准备 Busybox

进入下载软件包，https://busybox.net/downloads/

wget https://busybox.net/downloads/busybox-1.36.1.tar.bz2
tar -xvf busybox-1.36.1.tar.bz2
mv busybox-1.36.1 busybox
cd busybox

配置编译选项

make CROSS_COMPILE=riscv64-unknown-linux-gnu- menuconfig

选择静态库模式，设置路径：Settings -> Build static binary (no shared libs)

Responsive Image

编译 Busybox

make CROSS_COMPILE=riscv64-unknown-linux-gnu- -j $(nproc)

如果需要频繁编译，也可以在 Menuconfig 中设置交叉编译器路径，这样就不需要每次都指定了。设置路径为：Settings -> Build Options -> Cross Compiler prefix。将其设置为 riscv64-unknown-linux-gnu-。

安装 Busybox：

make CROSS_COMPILE=riscv64-unknown-linux-gnu- install

Busybox 默认安装在当前目录的_install 目录下，也可以在 Menuconfig 中设置安装目录，路径为：Settings -> Build Options -> Destination path for ‘make install’。

查看安装目录

ls _install 
bin  linuxrc  sbin  usr

制作根文件系统

qemu-img create -f raw rootfs.img 256M
mkfs.ext4 rootfs.img
mkdir rootfs
sudo mount -o loop rootfs.img rootfs
sudo cp -r _install/* rootfs

cd rootfs
sudo mkdir proc sys dev etc etc/init.d
cd etc
cd init.d
sudo touch rcS
sudo chmod +x rcS

sudo vim rcS

写入以下内容：

#!/bin/sh  
mount -t proc none /proc  
mount -t sysfs none /sys  
/sbin/mdev -s

sudo umount rootfs

qemu 启动内核：

#!/usr/bin/env bash
RESTORE=$(echo -en '\001\033[0m\002')
YELLOW=$(echo -en '\001\033[00;33m\002')

## Configuration
vcpu=8
memory=16
drive="/home/user/workspace/rootfs.img"
kernel=" /home/user/workspace/linux-stable/arch/riscv/boot/Image"
fw="/home/user/workspace/opensbi/build/platform/generic/firmware/fw_jump.bin"
ssh_port=12070

cmd="/home/user/program/riscv64-qemu/bin/qemu-system-riscv64 \
  -nographic -machine virt \
  -smp "$vcpu" -m "$memory"G \
  -cpu rv64\
  -bios "$fw" \
  -kernel "$kernel" \
  -drive file=$drive,format=raw,id=hd0 \
  -device virtio-blk-device,drive=hd0 \
  -append "root=/dev/vda console=ttyS0" "

echo ${YELLOW}:: Starting VM...${RESTORE}
echo ${YELLOW}:: Using following configuration${RESTORE}
echo ""
echo ${YELLOW}vCPU Cores: "$vcpu"${RESTORE}
echo ${YELLOW}Memory: "$memory"G${RESTORE}
echo ${YELLOW}Disk: "$drive"${RESTORE}
echo ${YELLOW}SSH Port: "$ssh_port"${RESTORE}
echo ""
echo ${YELLOW}:: NOTE: Make sure ONLY ONE .qcow2 file is${RESTORE}
echo ${YELLOW}in the current directory${RESTORE}
echo ""
echo ${YELLOW}:: Tip: Try setting DNS manually if QEMU user network doesn\'t work well. ${RESTORE}
echo ${YELLOW}:: HOWTO -\> https://serverfault.com/a/810639 ${RESTORE}
echo ""
echo ""

sleep 2

eval $cmd

Responsive Image

uCore-实验第 0 章 - 实验环境搭建

Fri, 08 Sep 2023 10:46:20 +0000

本次实验是清华大学操作系统课程的课程实验，实验内容是基于 RISC-V 架构的 uCore 操作系统。本次实验的目的是搭建实验环境，为后续实验做准备。指导书参考uCore-Tutorial-Guide-2023S 文档。本系列文章内容主要是指导书的补充以及我在实验过程的一些理解。

本章没有什么需要特别说明的，指导手册十分详细，按照指导手册的步骤一步步来就可以了。因为平时也在用 WSL2 开发，所以配置十分顺利，没有遇到什么问题。这篇文章就当占坑了，如果后续有什么需要补充的再来更新。

uCore-实验第 1 章 - 应用程序与基本执行环境

Fri, 08 Sep 2023 10:45:14 +0000

了解系统调用

操作系统的系统调用（syscall）是操作系统提供给应用程序使用的一种接口。它允许应用程序通过向操作系统发送请求，来执行一些必须由操作系统来完成的任务，例如读取文件、创建进程、分配内存等。

通俗地说，可以把操作系统看作一个巨大的服务员，而应用程序就像是顾客。应用程序不能直接访问硬件或执行特权操作，因为这样可能会导致系统不稳定或不安全。所以，应用程序需要通过系统调用来与操作系统进行交互，请求操作系统代表它完成某些任务。

当应用程序需要操作系统执行特定的功能时，它会调用适当的系统调用函数，并传递参数给它。然后操作系统会接收到这个请求，并根据请求的类型和参数来执行相应的操作。完成后，操作系统会将执行结果返回给应用程序。

在 RISC-V 架构中，系统调用是通过使用特定的指令来实现的。具体来说，RISC-V 架构提供了一个称为 ecall（environment call）的指令来触发系统调用。

要使用 syscall，在 RISC-V 汇编代码中可以通过以下步骤来完成：

将系统调用编号（syscall number）放入寄存器 a7 中，该编号对应于所需的系统调用功能。
将系统调用所需的参数放入其他相应的寄存器中。例如，参数传递给文件读取系统调用可能需要将文件描述符放入 a0 寄存器，缓冲区地址放入 a1 寄存器，以及读取的字节数放入 a2 寄存器。
执行 ecall 指令。这会触发操作系统处理当前运行的程序的系统调用请求。
操作系统接收到系统调用请求后，根据寄存器 a7 中的系统调用编号和其他寄存器中的参数来执行相应的操作。
当操作系统完成系统调用请求时，它将结果放入适当的寄存器中，通常是 a0 寄存器。
程序继续执行，可以检查结果并进行后续的处理。

需要注意的是，具体的系统调用编号以及参数的传递方式会根据操作系统的实现而有所不同。所以在编写 RISC-V 汇编代码时，需要参考操作系统的相关文档来了解具体的系统调用接口和参数传递方式。

makr run 之后发生了什么？

当执行make run命令后，以下是运行流程的概述：

内核代码编译：执行make run会触发 Makefile 中的相应规则，从而编译生成内核（kernel）二进制文件。
加载 kernel 并启动 QEMU：根据 QEMUOPTS 变量指定的参数，QEMU 加载生成的 kernel 二进制文件，并启动模拟器。
引导代码执行：在模拟器启动后，CPU 的通用寄存器被清零，程序计数器（PC）指向 0x1000 的位置，这里有硬件固化的一小段引导代码。该引导代码会迅速跳转到 0x80000000 处的 RustSBI（Rust Supervisor Binary Interface）。
RustSBI 完成硬件初始化：RustSBI 是一个用于与操作系统进行交互的接口层。在跳转到 RustSBI 之后，它会完成必要的硬件初始化工作。
执行操作系统第一条指令：RustSBI 在完成硬件初始化后，会跳转到 kernel 二进制文件所在内存位置 0x80200000 处，并开始执行我们操作系统的第一条指令。

综上所述，执行make run命令会完成内核的编译和加载，启动 QEMU 虚拟机，并经过引导代码和 RustSBI 的处理，最终开始执行操作系统的第一条指令。

了解链接脚本

# kernel.ld
BASE_ADDRESS = 0x80200000;
SECTIONS
{
   . = BASE_ADDRESS;
   skernel = .;

   stext = .;
   .text : {
      *(.text.entry)   # 第一行代码
      *(.text .text.*)
   }

   ...
}

kernel.ld 中的 `BASE_ADDRESS = 0x80200000` 指定了内核的加载地址，这个地址哪来的？

以下内容摘自参考rCore-Tutorial-Book-v3 3.6.0-alpha.1 文档：

在 Qemu 模拟的 virt 硬件平台上，物理内存的起始物理地址为 0x80000000，物理内存的默认大小为 128MiB，它可以通过 -m 选项进行配置。如果使用默认配置的 128MiB 物理内存则对应的物理地址区间为 [0x80000000,0x88000000) 。如果使用上面给出的命令启动 Qemu，那么在 Qemu 开始执行任何指令之前，首先把两个文件加载到 Qemu 的物理内存中：即作把作为 bootloader 的 rustsbi-qemu.bin 加载到物理内存以物理地址 0x80000000 开头的区域上，同时把内核镜像 os.bin 加载到以物理地址 0x80200000 开头的区域上。

为什么加载到这两个位置呢？这与 Qemu 模拟计算机加电启动后的运行流程有关。一般来说，计算机加电之后的启动流程可以分成若干个阶段，每个阶段均由一层软件或固件负责，每一层软件或固件的功能是进行它应当承担的初始化工作，并在此之后跳转到下一层软件或固件的入口地址，也就是将计算机的控制权移交给了下一层软件或固件。Qemu 模拟的启动流程则可以分为三个阶段：第一个阶段由固化在 Qemu 内的一小段汇编程序负责；第二个阶段由 bootloader 负责；第三个阶段则由内核镜像负责。

第一阶段：将必要的文件载入到 Qemu 物理内存之后，Qemu CPU 的程序计数器（PC, Program Counter）会被初始化为 0x1000，因此 Qemu 实际执行的第一条指令位于物理地址 0x1000，接下来它将执行寥寥数条指令并跳转到物理地址 0x80000000 对应的指令处并进入第二阶段。从后面的调试过程可以看出，该地址 0x80000000 被固化在 Qemu 中，作为 Qemu 的使用者，我们在不触及 Qemu 源代码的情况下无法进行更改。

第二阶段：由于 Qemu 的第一阶段固定跳转到 0x80000000，我们需要将负责第二阶段的 bootloader rustsbi-qemu.bin 放在以物理地址 0x80000000 开头的物理内存中，这样就能保证 0x80000000 处正好保存 bootloader 的第一条指令。在这一阶段，bootloader 负责对计算机进行一些初始化工作，并跳转到下一阶段软件的入口，在 Qemu 上即可实现将计算机控制权移交给我们的内核镜像 os.bin。这里需要注意的是，对于不同的 bootloader 而言，下一阶段软件的入口不一定相同，而且获取这一信息的方式和时间点也不同：入口地址可能是一个预先约定好的固定的值，也有可能是在 bootloader 运行期间才动态获取到的值。我们选用的 RustSBI 则是将下一阶段的入口地址预先约定为固定的 0x80200000，在 RustSBI 的初始化工作完成之后，它会跳转到该地址并将计算机控制权移交给下一阶段的软件——也即我们的内核镜像。

第三阶段：为了正确地和上一阶段的 RustSBI 对接，我们需要保证内核的第一条指令位于物理地址 0x80200000 处。为此，我们需要将内核镜像预先加载到 Qemu 物理内存以地址 0x80200000 开头的区域上。一旦 CPU 开始执行内核的第一条指令，证明计算机的控制权已经被移交给我们的内核，也就达到了本节的目标。

以上过程是 QEMU 中的启动流程，真实计算机的加电启动流程大致如下：第一阶段：加电后 CPU 的 PC 寄存器被设置为计算机内部只读存储器（ROM，Read-only Memory）的物理地址，随后 CPU 开始运行 ROM 内的软件。我们一般将该软件称为固件（Firmware），它的功能是对 CPU 进行一些初始化操作，将后续阶段的 bootloader 的代码、数据从硬盘载入到物理内存，最后跳转到适当的地址将计算机控制权转移给 bootloader。它大致对应于 Qemu 启动的第一阶段，即在物理地址 0x1000 处放置的若干条指令。可以看到 Qemu 上的固件非常简单，因为它并不需要负责将 bootloader 从硬盘加载到物理内存中，这个任务此前已经由 Qemu 自身完成了。第二阶段：bootloader 同样完成一些 CPU 的初始化工作，将操作系统镜像从硬盘加载到物理内存中，最后跳转到适当地址将控制权转移给操作系统。可以看到一般情况下 bootloader 需要完成一些数据加载工作，这也就是它名字中 loader 的来源。它对应于 Qemu 启动的第二阶段。在 Qemu 中，我们使用的 RustSBI 功能较弱，它并没有能力完成加载的工作，内核镜像实际上是和 bootloader 一起在 Qemu 启动之前加载到物理内存中的。第三阶段：控制权被转移给操作系统。由于篇幅所限后面我们就不再赘述了。值得一提的是，为了让计算机的启动更加灵活，bootloader 目前可能非常复杂：它可能也分为多个阶段，并且能管理一些硬件资源，从复杂性上它已接近一个传统意义上的操作系统。

终端是如何控制颜色的？

enum LOG_COLOR {
	RED = 31,
	GREEN = 32,
	BLUE = 34,
	GRAY = 90,
	YELLOW = 93,
};

#if defined(USE_LOG_ERROR)
#define errorf(fmt, ...)                                               \
	do {                                                               \
		int tid = threadid();                                          \
		printf("\x1b[%dm[%s %d]" fmt "\x1b[0m\n", RED, "ERROR", tid,   \
		       ##__VA_ARGS__);                                         \
	} while (0)
#else

ANSI 转义码是一种用于控制终端输出的特殊字符序列。它们由\x1b（或\033）开头，后面跟着一系列数字和分号组成。

ANSI 转义码中的数字部分用于指定不同的控制操作，如设置文本颜色、背景颜色、光标位置等等。其中，用于设置颜色的转义码包括三个主要的部分：\x1b[颜色代码m。

具体来说，\x1b[表示开始使用控制序列，接下来的数字代表不同的颜色代码，最后的m表示结束控制序列。例如，\x1b[31m表示将文本颜色设置为红色，而\x1b[0m用于重置所有属性为默认值。

当终端遇到这样的转义序列时，它会解析并执行相应的控制操作，从而实现对文本颜色、背景颜色和其他属性的控制。

需要注意的是，不同的终端可能支持不同的 ANSI 转义码，并且不同操作系统也可能有不同的实现。因此，在编写使用 ANSI 转义码的代码时，建议先测试并确保其在目标终端上正常工作。

更多详细解释可以参考文章：终端颜色控制 - 简书。

应用程序输出字符会调用 SBI 服务，SBI 中发生了什么？

因为对 Rust 语言不熟悉，所以这里的分析是基于 C 语言的 OpenSBI 来分析的，他们的逻辑是一样的。如果有熟悉 Rust 的可以查看 RustSBI 源码

根据指导书中的解释以及阅读代码，我们知道调用了 printf 最终实际上是调用了 sbi_call。那么 sbi_call 是如何实现的呢？因为我是做驱动开发以及固件开发的，也经常需要使用 OpenSBI，所想多问一句，OpenSBI 是如何实现的呢？OpenSBI 是如何提供服务的呢？它是如何打印出字符的呢？

内核中的 SBI 调用

我们先看一下内核中的 sbi_call 都做了写啥。

// uCore-Tutorial-Code-2023S/os/sbi.c
const uint64 SBI_CONSOLE_PUTCHAR = 1;

void console_putchar(int c)
{
	sbi_call(SBI_CONSOLE_PUTCHAR, c, 0, 0);
}

// uCore-Tutorial-Code-2023S/os/sbi.c
int inline sbi_call(uint64 which, uint64 arg0, uint64 arg1, uint64 arg2)
{
    // 使用寄存器变量来保存参数值和系统调用编号
    register uint64 a0 asm("a0") = arg0;  // 将 'arg0' 的值保存在寄存器 'a0' 中
    register uint64 a1 asm("a1") = arg1;  // 将 'arg1' 的值保存在寄存器 'a1' 中
    register uint64 a2 asm("a2") = arg2;  // 将 'arg2' 的值保存在寄存器 'a2' 中
    register uint64 a7 asm("a7") = which; // 将 'which' 的值保存在寄存器 'a7' 中
    // 内联汇编代码使用 ecall 指令进行系统调用
    asm volatile(
        "ecall"  // 使用 ecall 指令进行系统调用
        // 在这段代码中，指令 "ecall" 的输入参数是寄存器 a0 a1 a2 和 a7，输出参数是寄存器 a0
        : "=r"(a0)  // 输出操作数：将返回值存储在变量 'a0' 中
        : "r"(a0), "r"(a1), "r"(a2), "r"(a7)  // 输入操作数：传递参数和系统调用编号
        : "memory"  //  "memory" 标志告诉编译器，这条指令可能会修改内存中的数据，需要进行内存屏障操作来保证数据的正确性。 
    );
    return a0;  // 返回存储在变量 'a0' 中的值
}

那么 OpenSBI 如何提供服务？在include/sbi/sbi_ecall.h这种定义了每个ecall服务全局变量。

//include/sbi/sbi_ecall.h
extern struct sbi_ecall_extension ecall_base;
extern struct sbi_ecall_extension ecall_legacy;
extern struct sbi_ecall_extension ecall_time;
extern struct sbi_ecall_extension ecall_rfence;
extern struct sbi_ecall_extension ecall_ipi;
extern struct sbi_ecall_extension ecall_vendor;
extern struct sbi_ecall_extension ecall_hsm;
extern struct sbi_ecall_extension ecall_srst;

在lib/sbi/sbi_ecall.c中注册了所有的ecall服务，并将其加到链表ecall_exts_list中。

int sbi_ecall_init(void)
{
	int ret;
	struct sbi_ecall_extension *ext;
	unsigned long i;

	for (i = 0; i < sbi_ecall_exts_size; i++) {
		ext = sbi_ecall_exts[i];
		ret = sbi_ecall_register_extension(ext);
		if (ret)
			return ret;
	}

	return 0;
}
int sbi_ecall_register_extension(struct sbi_ecall_extension *ext)
{
	struct sbi_ecall_extension *t;

	if (!ext || (ext->extid_end < ext->extid_start) || !ext->handle)
		return SBI_EINVAL;

	sbi_list_for_each_entry(t, &ecall_exts_list, head) {
		unsigned long start = t->extid_start;
		unsigned long end = t->extid_end;
		if (end < ext->extid_start || ext->extid_end < start)
			/* no overlap */;
		else
			return SBI_EINVAL;
	}

	SBI_INIT_LIST_HEAD(&ext->head);
	sbi_list_add_tail(&ext->head, &ecall_exts_list);

	return 0;
}

/**
 * Iterate over list of given type
 * @param pos the type * to use as a loop cursor.
 * @param head the head for your list.
 * @param member the name of the list_struct within the struct.
 */
#define sbi_list_for_each_entry(pos, head, member) \
	for (pos = sbi_list_entry((head)->next, typeof(*pos), member);	\
	     &pos->member != (head); 	\
	     pos = sbi_list_entry(pos->member.next, typeof(*pos), member))

那么服务 id 如何和相对应的服务绑定的呢？以ecall_time为例，查看其结构体原型struct sbi_ecall_extension ：

// include/sbi/sbi_ecall.h: 23
struct sbi_ecall_extension {
	struct sbi_dlist head;
	unsigned long extid_start;
	unsigned long extid_end;
	int (* probe)(unsigned long extid, unsigned long *out_val);
	int (* handle)(unsigned long extid, unsigned long funcid,
		       const struct sbi_trap_regs *regs,
		       unsigned long *out_val,
		       struct sbi_trap_info *out_trap);
};

可以看到有 extid_start、extid_end 和 handle。

目前 OpenSBI 逐步将每个服务的实现都放在了lib/sbi单独文件中，以ecall_time为例，其实现在lib/sbi/sbi_ecall_time.c中。单独为其绑定回调处理函数sbi_ecall_time_handler。但是还有很多服务的实现还是放在了lib/sbi/sbi_ecall_legacy.c中，后续应该会逐步迁移。我们上文使用的SBI_CONSOLE_PUTCHAR服务就是在这里实现的。

// lib/sbi/sbi_ecall_legacy.c
struct sbi_ecall_extension ecall_legacy = {
	.extid_start = SBI_EXT_0_1_SET_TIMER,
	.extid_end = SBI_EXT_0_1_SHUTDOWN,
	.handle = sbi_ecall_legacy_handler,
};

static int sbi_ecall_legacy_handler(unsigned long extid, unsigned long funcid,
				    const struct sbi_trap_regs *regs,
				    unsigned long *out_val,
				    struct sbi_trap_info *out_trap)
{
	int ret = 0;
	struct sbi_tlb_info tlb_info;
	u32 source_hart = current_hartid();
	ulong hmask = 0;

	switch (extid) {
	case SBI_EXT_0_1_SET_TIMER:
		sbi_timer_event_start((u64)regs->a0);
		break;
	case SBI_EXT_0_1_CONSOLE_PUTCHAR:
		sbi_putc(regs->a0);
		break;
	case SBI_EXT_0_1_CONSOLE_GETCHAR:
		ret = sbi_getc();
		break;
	// ...
	};

	return ret;
}

这就把 id 与相应的服务函数绑定。一个extid对应一个handler。

我们可以在找到SBI_EXT_0_1_CONSOLE_PUTCHAR的值，是与 Linux 内核里定义的值是一致的。

// include/sbi/sbi_ecall_interface.h
/* SBI Extension IDs */
#define SBI_EXT_0_1_CONSOLE_PUTCHAR		0x1

ecall 服务调用流程

在 firmware/fw_base.S 中注册了 Machine Mode 的 trap handler，即 sbi_trap_handler；

_start_warm:
    /* Setup trap handler */
    la	a4, _trap_handler
    csrw	CSR_MTVEC, a4  /* CSR_MTVEC = _trap_handler */

_trap_handler:
    TRAP_SAVE_AND_SETUP_SP_T0

    TRAP_SAVE_MEPC_MSTATUS 0

    TRAP_SAVE_GENERAL_REGS_EXCEPT_SP_T0

    TRAP_CALL_C_ROUTINE

    TRAP_RESTORE_GENERAL_REGS_EXCEPT_SP_T0

    TRAP_RESTORE_MEPC_MSTATUS 0

    TRAP_RESTORE_SP_T0

    mret

.macro	TRAP_CALL_C_ROUTINE
    /* Call C routine */
    add	a0, sp, zero
    call	sbi_trap_handler
.endm

在 lib/sbi/sbi_trap.c 中定义了 sbi_trap_handler，处理各种 mcause，比如 Illegal Instructions，Misaligned Load & Store, Supervisor & Machine Ecall 等。

// lib/sbi/sbi_trap.c
void sbi_trap_handler(struct sbi_trap_regs *regs)
{
    ...

    switch (mcause) {
    case CAUSE_ILLEGAL_INSTRUCTION:
        rc  = sbi_illegal_insn_handler(mtval, regs);
        break;
    case CAUSE_MISALIGNED_LOAD:
        rc = sbi_misaligned_load_handler(mtval, mtval2, mtinst, regs);
        break;
    case CAUSE_MISALIGNED_STORE:
        rc  = sbi_misaligned_store_handler(mtval, mtval2, mtinst, regs);
        break;
    case CAUSE_SUPERVISOR_ECALL:
    case CAUSE_MACHINE_ECALL:
        rc  = sbi_ecall_handler(regs);
        break;
    default:
        /* If the trap came from S or U mode, redirect it there */
        trap.epc = regs->mepc;
        trap.cause = mcause;
        trap.tval = mtval;
        trap.tval2 = mtval2;
        trap.tinst = mtinst;
        rc = sbi_trap_redirect(regs, &trap);
        break;
    };

    ...

在 lib/sbi/sbi_ecall.c 中定义了处理 ecall mcause 的 sbi_ecall_handler，它遍历上面 ecall_exts_list 中注册的各种 ecall 服务。

sbi_ecall_handler 根据 Linux 内核传递的 ext (extension id) 找到链表中对应的 ecall 服务，执行其中的 handle 函数，该函数根据 fid 执行具体的服务内容。

// lib/sbi/sbi_ecall.c
int sbi_ecall_handler(struct sbi_trap_regs *regs)
{
    // ...
    unsigned long extension_id = regs->a7;
    unsigned long func_id = regs->a6;
    struct sbi_trap_info trap = {0};
    unsigned long out_val = 0;

    // 遍历所有 ecall 服务
    ext = sbi_ecall_find_extension(extension_id);
    if (ext && ext->handle) {
        // 如果找到了就执行
        ret = ext->handle(extension_id, func_id,
                regs, &out_val, &trap);
        if (extension_id >= SBI_EXT_0_1_SET_TIMER &&
            extension_id <= SBI_EXT_0_1_SHUTDOWN)
            is_0_1_spec = 1;
    } else {
        ret = SBI_ENOTSUPP;
    }

    ...
}

我们可以发现 extension_id 就是 a7 寄存器，他和我们在 uCore OS 中定义的 SBI_EXT_0_1_CONSOLE_PUTCHAR 是一致的。

程序的内存布局与编译流程

程序的内存布局

uCore 的编译系统

.PHONY: clean build user
# 设置伪目标clean、build和user，可以通过命令make来执行这些目标

all: build_kernel
# 默认目标为build_kernel，即执行build_kernel目标下的指令

LOG ?= error
# 定义一个变量LOG，默认值是error

K = os
TOOLPREFIX = riscv64-unknown-elf-

CC = $(TOOLPREFIX)gcc
AS = $(TOOLPREFIX)gcc
LD = $(TOOLPREFIX)ld
OBJCOPY = $(TOOLPREFIX)objcopy
OBJDUMP = $(TOOLPREFIX)objdump
PY = python3
GDB = $(TOOLPREFIX)gdb
CP = cp

MKDIR_P = mkdir -p

BUILDDIR = build

C_SRCS = $(wildcard $K/*.c)
# 定义一个变量C_SRCS，使用wildcard函数匹配所有以.c为后缀的文件，并存储在$K目录下

AS_SRCS = $(wildcard $K/*.S)
# 定义一个变量AS_SRCS，使用wildcard函数匹配所有以.S为后缀的文件，并存储在$K目录下

C_OBJS = $(addprefix $(BUILDDIR)/, $(addsuffix .o, $(basename $(C_SRCS))))
# 定义一个变量C_OBJS，通过addprefix和addsuffix函数将$(C_SRCS)中的路径替换为$(BUILDDIR)，并将后缀修改为.o

AS_OBJS = $(addprefix $(BUILDDIR)/, $(addsuffix .o, $(basename $(AS_SRCS))))
# 定义一个变量AS_OBJS，通过addprefix和addsuffix函数将$(AS_SRCS)中的路径替换为$(BUILDDIR)，并将后缀修改为.o

OBJS = $(C_OBJS) $(AS_OBJS)
# 定义一个变量OBJS，其值为$(C_OBJS)和$(AS_OBJS)的组合

HEADER_DEP = $(addsuffix .d, $(basename $(C_OBJS)))
# 定义一个变量HEADER_DEP，通过addsuffix函数将$(C_OBJS)中的后缀修改为.d

-include $(HEADER_DEP)
# 包含$(HEADER_DEP)中的.d文件

CFLAGS = -Wall -Werror -O -fno-omit-frame-pointer -ggdb
# 定义一个变量CFLAGS，并赋值为-Wall -Werror -O -fno-omit-frame-pointer -ggdb

CFLAGS += -MD
# 将-MD选项追加到CFLAGS变量中，用于自动生成依赖关系文件

CFLAGS += -mcmodel=medany
# 将-mcmodel=medany选项追加到CFLAGS变量中，用于指定内存模型

CFLAGS += -ffreestanding -fno-common -nostdlib -mno-relax
# 将-ffreestanding -fno-common -nostdlib -mno-relax选项追加到CFLAGS变量中，用于编译无操作系统环境下的程序

CFLAGS += -I$K
# 将-I$K选项追加到CFLAGS变量中，用于指定头文件搜索路径为$K目录下

CFLAGS += $(shell $(CC) -fno-stack-protector -E -x c /dev/null >/dev/null 2>&1 && echo -fno-stack-protector)
# 将$(CC) -fno-stack-protector -E -x c /dev/null >/dev/null 2>&1 && echo -fno-stack-protector命令执行结果追加到CFLAGS变量中，用于禁用栈保护机制

ifeq ($(LOG), error)
CFLAGS += -D LOG_LEVEL_ERROR
else ifeq ($(LOG), warn)
CFLAGS += -D LOG_LEVEL_WARN
else ifeq ($(LOG), info)
CFLAGS += -D LOG_LEVEL_INFO
else ifeq ($(LOG), debug)
CFLAGS += -D LOG_LEVEL_DEBUG
else ifeq ($(LOG), trace)
CFLAGS += -D LOG_LEVEL_TRACE
endif
# 根据$(LOG)变量的值，向CFLAGS变量追加相应的预处理器选项，相当于添加了一个宏定义，log.h中的LOG_LEVEL_ERROR等宏定义会根据这个宏定义来决定是否生效

# Disable PIE when possible (for Ubuntu 16.10 toolchain)
ifneq ($(shell $(CC) -dumpspecs 2>/dev/null | grep -e '[^f]no-pie'),)
CFLAGS += -fno-pie -no-pie
endif
ifneq ($(shell $(CC) -dumpspecs 2>/dev/null | grep -e '[^f]nopie'),)
CFLAGS += -fno-pie -nopie
endif
# 根据系统环境判断是否支持PIE（位置无关执行）选项，并根据情况向CFLAGS变量追加相应的选项

LDFLAGS = -z max-page-size=4096
# 定义一个变量LDFLAGS，并赋值为-z max-page-size=4096

$(AS_OBJS): $(BUILDDIR)/$K/%.o : $K/%.S
    @mkdir -p $(@D)
    $(CC) $(CFLAGS) -c $< -o $@
# 规则：生成$(AS_OBJS)目标所需的依赖文件$(BUILDDIR)/$K/%.o，依赖于$K/%.S，并通过$(CC)命令编译生成目标文件

$(C_OBJS): $(BUILDDIR)/$K/%.o : $K/%.c  $(BUILDDIR)/$K/%.d
    @mkdir -p $(@D)
    $(CC) $(CFLAGS) -c $< -o $@
# 规则：生成$(C_OBJS)目标所需的依赖文件$(BUILDDIR)/$K/%.o，依赖于$K/%.c和$(BUILDDIR)/$K/%.d，并通过$(CC)命令编译生成目标文件

$(HEADER_DEP): $(BUILDDIR)/$K/%.d : $K/%.c
    @mkdir -p $(@D)
    @set -e; rm -f $@; $(CC) -MM $< $(INCLUDEFLAGS) > $@.$$$$; \
        sed 's,\($*\)\.o[ :]*,\1.o $@ : ,g' < $@.$$$$ > $@; \
        rm -f $@.$$$$
# 规则：生成$(HEADER_DEP)目标所需的依赖文件$(BUILDDIR)/$K/%.d，依赖于$K/%.c，并通过$(CC)命令生成依赖关系文件

build: build/kernel
# 定义一个目标build，其依赖于build/kernel

build/kernel: $(OBJS)
    $(LD) $(LDFLAGS) -T os/kernel.ld -o $(BUILDDIR)/kernel $(OBJS)
    $(OBJDUMP) -S $(BUILDDIR)/kernel > $(BUILDDIR)/kernel.asm
    $(OBJDUMP) -t $(BUILDDIR)/kernel | sed '1,/SYMBOL TABLE/d; s/ .* / /; /^$$/d' > $(BUILDDIR)/kernel.sym
    @echo 'Build kernel done'
# 规则：生成build/kernel目标，依赖于$(OBJS)，通过$(LD)命令连接生成kernel，并通过$(OBJDUMP)命令生成汇编文件和符号表

clean:
    rm -rf $(BUILDDIR)

# BOARD
BOARD		?= qemu
SBI			?= rustsbi
BOOTLOADER	:= ./bootloader/rustsbi-qemu.bin

QEMU = qemu-system-riscv64
QEMUOPTS = \
	-nographic \
	-machine virt \
	-bios $(BOOTLOADER) \
	-kernel build/kernel	\

run: build/kernel
	$(QEMU) $(QEMUOPTS)

# QEMU's gdb stub command line changed in 0.11
QEMUGDB = $(shell if $(QEMU) -help | grep -q '^-gdb'; \
	then echo "-gdb tcp::15234"; \
	else echo "-s -p 15234"; fi)

# 启动QEMU并通过GDB调试，此时QEMu会进入后台运行，并暂停执行，等待GDB连接
# 连接的GDB端口为15234
debug: build/kernel .gdbinit
	$(QEMU) $(QEMUOPTS) -S $(QEMUGDB) &
	sleep 1
	$(GDB)

编译、运行 uCore 的一些常用命令有如下一些，涉及了后续章节中引入的测试用例中的命令：

make run
make debug
make clean
# 编译测试用例的前四章
make user CHAPTER=4 LOG=trace
# 编译测试用例的第四章
make user CHAPTER=4_only LOG=trace
# 只运行测试用例的第四章
make test CHAPTER=4_only

附录

makefile 和 qemu

AS = $(TOOLPREFIX)gas > AS = $(TOOLPREFIX)as

参考资料

终端颜色控制 - 简书

uCore 实验第 5 章 - 进程及进程管理

Fri, 08 Sep 2023 10:01:20 +0000

首先，.section .data 表示定义了一个数据段，在这个段中定义了一系列的全局变量。其中，_app_num 是一个标签，表示一个 64 位的整数，初始值为 23。接下来是一系列的标签，分别代表了应用程序的起始地址，每个标签都是 64 位的整数。

接着，.section .data 后面又出现了一个标签 _app_names，它是一个字符串数组，包含了一组字符串，分别命名为 “ch2b_exit”、“ch2b_hello_world”、“ch2b_power” 等等。这些字符串名字对应了前面定义的应用程序的起始地址。

再往下，出现了一个标签 INIT_PROC，它是一个字符串，表示初始化进程的名称，值为 “usershell”。

之后，每个应用程序都有自己的标签和段名，比如 app_0_start、app_1_start 等等。每个标签都包含一个指令 .incbin，它用于将一个二进制文件（以字符串形式指定文件路径）插入到当前段中。

进程初始化分析

scheduler()
    fetch_task() // 获取下一个要执行的进程
    swtch(&curenv->context, nextenv->context) // 切换到下一个进程上下文

// Per-process state
struct proc {
    enum procstate    state;     // 进程状态
    int               pid;       // 进程 ID
    uint64            ustack;    // 进程用户栈虚拟地址 (用户页表)
    uint64            kstack;    // 进程内核栈虚拟地址 (内核页表)
    struct trapframe *trapframe; // 进程中断帧
    struct context    context; // 用于保存进程内核态的寄存器信息，进程切换时使用
    pagetable_t       pagetable; // User page table
    uint64            max_page;
    uint64            program_brk;
    uint64            heap_bottom;
    struct proc *     parent; // Parent process
    uint64            exit_code;
    struct file *     files[FD_BUFFER_SIZE];
    uint32     syscall_times[MAX_SYSCALL_NUM]; // 系统调用次数统计
    uint64     start_time;                     // 进程开始运行时间
    struct vma vmas[NVMA];                     // 虚拟内存区域
};

wait 系统调用的功能

wait 系统调用是用于处理子进程终止状态的系统调用。其主要功能是等待子进程的终止，并获取子进程的退出状态信息。在操作系统中，当一个父进程创建了一个子进程后，通常会使用 wait 来等待子进程的终止，以便进行后续的处理，如回收子进程的资源或获取其运行结果。

以下是 wait 系统调用的主要功能：

等待子进程终止：父进程调用 wait 系统调用后，会进入阻塞状态，等待子进程终止。如果子进程已经终止，那么 wait 立即返回，否则父进程会一直等待直到子进程终止。
获取子进程的退出状态：wait 系统调用会获取子进程的退出状态信息，包括子进程的退出码（通常是一个整数）。这个退出码可以告诉父进程子进程的终止情况，例如是否成功执行等。
回收子进程资源：一旦子进程终止，其占用的系统资源（如内存、文件描述符等）通常需要由父进程来回收，以避免资源泄漏。wait 系统调用在等待子进程终止后，会自动回收这些资源。
处理僵尸进程：在某些情况下，子进程可能会在终止后成为僵尸进程，即已经终止但其进程描述符仍然存在。父进程可以使用 wait 来回收这些僵尸进程，释放相关资源。

exec、fork 和 spawn 是操作系统中常见的进程管理系统调用，各自具有不同的功能和用途：

exec 系统调用：
- 功能：exec 系统调用用于在当前进程的上下文中加载并执行一个新的程序。
- 用途：通常在一个进程需要替换自身的执行映像时使用。它会加载一个新的可执行文件，覆盖当前进程的地址空间和代码段，然后开始执行新的程序。这个新程序可以是完全不同的程序，从而允许进程动态切换到不同的应用程序，而不需要创建新的进程。
fork 系统调用：
- 功能：fork 系统调用用于创建一个与当前进程几乎完全相同的新进程，包括代码、数据和上下文等。
- 用途：通常用于创建新的进程，新进程称为子进程，它从父进程继承了大部分状态，然后可以在独立的地址空间中执行不同的操作。fork 创建的子进程是父进程的副本，可以并行执行不同的任务。
spawn 系统调用：
- 功能：spawn 系统调用通常用于创建新的进程并执行指定的程序。
- 用途：类似于 fork，它也创建了一个新的进程，但不像 fork 那样完全复制父进程。相反，spawn 允许你指定一个新程序的路径和参数，而不是完全复制当前进程的状态。这使得它更适合用于启动新程序，而不是简单地创建一个进程副本。

总结：

exec 用于替换当前进程的执行映像，允许加载和执行新程序。
fork 用于创建一个几乎与父进程相同的新进程，新进程成为父进程的副本。
spawn 通常用于创建一个新进程并执行指定的程序，允许指定不同的程序路径和参数。

附录

本章任务：在次 -> 在此

uCore 实验第 4 章 - 地址空间

Mon, 04 Sep 2023 11:11:48 +0000

为何指定 TRAMPOLINE 和 TRAPFRAME 在 va 的最高位？ TRAMPOLINE 和 TRAPFRAME 被定义在最高的虚拟内存地址上，是因为它们在操作系统的内存布局中起着重要作用。 TRAMPOLINE 被用作从用户模式切换到内核模式的跳转目标。当发生异常或中断时，处理器将从用户模式切换到内核模式，并将控制权转移到内核中预定义的位置，也就是陷阱处理程序。TRAMPOLINE 页面被映射到最高虚拟地址，以便处理器能够在这个转换过程中方便地引用它。通过将其放置在最高地址，确保了无论系统的具体内存布局如何，它始终是可访问的。另一方面，TRAPFRAME 用于在发生异常或中断时存储机器状态。它包含寄存器、标志和其他操作系统处理异常所需的信息。TRAPFRAME 也被放置在最高的虚拟地址上，以确保它易于访问，并且陷阱处理程序可以高效地访问它。通过将 TRAMPOLINE 和 TRAPFRAME 定义在最高的虚拟内存地址上，内核可以方便而可靠地处理异常和中断，而无需关心它们在内存中的特定位置。

如何确定分页方案 - satp

在 MMU 没有使能的情况下，虚拟地址和物理地址是相同的。在 MMU 使能的情况下，虚拟地址会被转换成物理地址。这个转换过程是由操作系统来管理的，操作系统需要维护一个数据结构来记录虚拟地址和物理地址的映射关系。这个数据结构就是页表。

转换的过程需要分页机制，分页机制有多种。RISC-V 的分页方案以 SvX 的模式命名，其中 X 是以位为单位的虚拟地址的长度。在 RV64 架构下，RISC-V 支持多种分页方案，包括 Sv39，Sv48，Sv57 以及 Sv64。Sv39 最大支持 39 位的虚拟地址，这意味着它可以支持 512 GB 的虚拟地址空间。Sv48 最大支持 48 位的虚拟地址，这意味着它可以支持 256 TB 的虚拟地址空间。我们将在本章中实现 Sv39 分页方案。

如何开启分页机制呢？RISC-V 的分页机制是通过 satp（Supervisor address translation and protection）寄存器来开启的。satp 寄存器字段分布如下：

Responsive Image

Mode 字段可以决定是否开启分页以及分页级数。Mode=0 时，不开启分页；Mode=8 时，开启 Sv39 分页机制。
ASID（Address Space Identifier，地址空间标识符）域是可选的，它可以用来降低上下文切换的开销。目前我们暂不考虑这个字段的作用。
PPN（Physical Page Number，物理页号），保存了根页表的物理地址。

SV39 多级页表机制

页表项描述

Responsive Image

Sv39 页表项（page-table entry，PTE）的布局，从左到右分别包含如下所述的域：

V 位决定了该页表项的其余部分是否有效 (V=1 时有效)。若 V=0，则任何遍历到此页表项的虚址转换操作都会导致页错误。
R、W 和 X 位分别表示此页是否可以读取、写入和执行。如果这三个位都是 0，那么这个页表项是指向下一级页表的指针，否则它是页表树的一个叶节点。
U 位表示该页是否是用户页面。若 U=0，则 U 模式不能访问此页面，但 S 模式可以。若 U=1，则 U 模式下能访问这个页面，而 S 模式不能。
G 位表示这个映射是否对所有虚址空间有效，硬件可以用这个信息来提高地址转换的性能。这一位通常只用于属于操作系统的页面。
A 位表示自从上次 A 位被清除以来，该页面是否被访问过。
D 位表示自从上次清除 D 位以来页面是否被弄脏（例如被写入）。
RSW 域留给操作系统使用，它会被硬件忽略。
PPN 域包含物理页号，这是物理地址的一部分。若这个页表项是一个叶节点，那么 PPN 是转换后物理地址的一部分。否则 PPN 给出下一节页表的地址。

虚拟地址转换物理地址过程

Responsive Image

当 satp 寄存器中开启分页时，S 模式和 U 模式中访存的地址都会被视为虚拟地址，需要将其转换为物理地址。虚拟地址转换物理地址的过程如下：

从 satp 寄存器中读取 PPN，得到根页表的物理地址，为了表述方便，我们将其记做三级页表基地址 satp.PPN；
从虚拟地址中取出三级虚拟页号 L2
处理器会读取地址位于 satp.PPN * 4096 + L2 * 4 的页表项，得到下一级页表的基地址 L1.PPN；
从虚拟地址中取出二级虚拟页号 L1
处理器会读取地址位于 L1.PPN * 4096 + L1 * 4 的页表项，得到下一级页表的基地址 L0.PPN；
从虚拟地址中取出一级虚拟页号 L0
处理器会读取地址位于 L0.PPN * 4096 + L0 * 4 的页表项，得到物理页号 PPN；
将 PPN 和虚拟地址的低 12 位也就是 Offset 拼接起来，得到物理地址。

我们看代码中是如何实现的：

#define PTE2PA(pte) (((pte) >> 10) << 12)
// 从虚拟地址中提取三个 9 位的页表索引
#define PXMASK 0x1FF // 9
// PGSHIFT = 12，这段宏定义用于定位 VPNx 的位置
#define PXSHIFT(level) (PGSHIFT + (9 * (level)))
// 从虚拟地址 VA 中提取出第 level 级页表的索引
#define PX(level, va) ((((uint64)(va)) >> PXSHIFT(level)) & PXMASK)

上面这三个工具宏可以用来提取虚拟页号 VPN。


// 返回页表 pagetable 中与虚拟地址 va 对应的 PTE 的地址。
// 如果 alloc != 0，则创建所需的页表页。
//
// RISC-V Sv39 方案有三级页表页。一个页表页包含 512 个 64 位的 PTEs。
// 一个 64 位的虚拟地址被分为五个字段：
//   39..63 -- 必须为零。
//   30..38 -- 2 级索引的 9 位。
//   21..29 -- 1 级索引的 9 位。
//   12..20 -- 0 级索引的 9 位。
//    0..11 -- 页面内的 12 位字节偏移量。
// pagetable 页表
// va 虚拟地址
// alloc 页表项不存在时是否分配
pte_t *walk(pagetable_t pagetable, uint64 va, int alloc)
{
    if (va >= MAXVA)
        panic("walk");

    for (int level = 2; level > 0; level--) {
        pte_t *pte = &pagetable[PX(level, va)];
        // 通过 PTE 的标志位判断每一级的 pte 是否是有效的（V 位）
        if (*pte & PTE_V) {
            pagetable = (pagetable_t)PTE2PA(*pte);
        } else {
            // 如果该项无效且 alloc 标志被设置，则分配一个新的页表
            // 如果 alloc 参数=0 或者已经没有空闲的内存了，那么遇到中途 V=0 的 pte 整个 walk 过程就会直接退出
            if (!alloc || (pagetable = (pde_t *)kalloc()) == 0) {
                return 0;
            }
            // 清空分配的页表
            memset(pagetable, 0, PGSIZE);
            // 更新页表项，将其指向新分配的页表，并设置有效位 PTE_V
            *pte = PA2PTE(pagetable) | PTE_V;
        }
    }
    // 返回最低级和虚拟地址的页表项，不是返回物理地址
    return &pagetable[PX(0, va)];
}

每次从虚拟地址 va 中提取出一个虚拟页号，然后根据这个虚拟页号从页表中取出下一级页表的基地址。如果这个页表项无效，那么根据 alloc 参数决定是否分配一个新的页表。如果 alloc 参数为 0 或者已经没有空闲的内存了，那么遇到中途 V=0 的 pte 整个 walk 过程就会直接退出。如果 alloc 参数为 1，那么就会分配一个新的页表，然后将这个页表项指向新分配的页表，并设置有效位 PTE_V。

我们可以发现 walk 返回的结果不是物理地址，而是页表项的地址。这是因为 walk 函数的作用是将虚拟地址转换为物理地址，而页表项中的 PPN 只是物理地址的一部分，还需要加上虚拟地址的低 12 位偏移量才能得到物理地址。

如何建立页表

前面的过程实际上是以用户的角度来考虑的，也就是给你一个虚拟地址按照分页的规则将其转化成物理地址就能访问了。但是作为一个操作系统，我们还需要多考虑一下，页表是哪来的？我们知道从虚拟地址中去获取页表地址，但是页表的内容是哪来的呢？页表是如何建立起来的呢？这些是需要操作系统来完成的。

建立页表也就是建立虚拟地址到物理地址的映射关系。也就是给你一个虚拟地址，你需要告诉我如何查到物理地址，实际上这个过程就是建立页表的过程。这个过程也是通过 walk 函数来完成的，从上文我们知道如果页表都建好的情况下 walk 就是不断查页表的过程，那么在没有页表的情况下，walk 还可以建立一个个页表。稍有不同的是，walk 返回的是最后一级页表项的地址，我们需要将物理地址写入这个页表项中。

在 uCore 中使用 mappages 函数封装了 walk 函数，具体如下：

#define PA2PTE(pa) ((((uint64)pa) >> 12) << 10)

/**
 * 为从虚拟地址 va 开始的页面创建指向物理地址 pa 开始的页表项（PTE）
 * 注意：va 和 size 可能不是页面对齐的
 * 如果无法分配所需的页表，则返回 0，否则返回 -1
 * 
 * @param pagetable 根页表地址
 * @param va        虚拟地址
 * @param size      映射的字节数
 * @param pa        物理地址
 * @param perm      权限位
 * @return          成功返回 0，否则返回 -1
 */
int mappages(pagetable_t pagetable, uint64 va, uint64 size, uint64 pa, int perm)
{
    uint64 virtualAddress, lastVirtualAddress;
    pte_t *pte;

    // 地址必须是页面对齐的
    virtualAddress     = PGROUNDDOWN(va);
    lastVirtualAddress = PGROUNDDOWN(va + size - 1);
    for (;;) {
        // 返回最低级的虚拟地址的页表项，如果不存在会创建一个新的页表项
        // 页表项可能会因为内存不足创建失败，如果创建失败，则返回 -1
        if ((pte = walk(pagetable, virtualAddress, 1)) == 0) {
            return -1;
        }
        // 如果 PTE 已经有效，则输出错误信息并返回 -1
        if (*pte & PTE_V) {
            errorf("remap");
            return -1;
        }
        // 将物理地址 pa 转换为页表项，并设置权限位 perm 和 有效位 PTE_V
        *pte = PA2PTE(pa) | perm | PTE_V;
        // 如果当前是最后一个地址，则结束循环
        if (virtualAddress == lastVirtualAddress) {
            break;
        }
        virtualAddress += PGSIZE;
        pa += PGSIZE;
    }
    return 0;
}

问答作业

请列举 SV39 页表页表项的组成，结合课堂内容，描述其中的标志位有何作用／潜在作用？

Sv39 页表页表项的组成如下：

有效位 (V)：这是页表项的最高位，用于指示页表项是否有效。如果有效位设置为 1，表示页表项有效，可以使用；如果设置为 0，表示页表项无效，禁止使用。这是虚拟内存中页表项的基本有效性标志。
写入位 (W)：这个标志位用于指示是否可以对此页进行写入操作。如果设置为 1，表示允许写入；如果设置为 0，表示禁止写入。它是页表项的访问权限控制标志之一。
用户位 (U)：用户位用于指示是否允许用户态程序访问此页。如果设置为 1，表示允许用户态访问；如果设置为 0，表示只允许内核态访问。它是页表项的访问权限控制标志之一。
执行位 (X)：执行位用于指示是否允许执行此页上的指令。如果设置为 1，表示允许执行；如果设置为 0，表示禁止执行。它也是页表项的访问权限控制标志之一。
全局位 (G)：全局位用于指示此页是否是全局的，即无需 TLB 缓存，通常用于内核页。如果设置为 1，表示是全局的；如果设置为 0，表示不是全局的。
已访问位 (A)：已访问位表示是否已经访问过此页，通常由硬件设置。操作系统可以用它来实现页面置换算法，如 LRU。
已修改位 (D)：已修改位表示是否已经对此页进行了写入操作。与已访问位类似，操作系统可以用它来实现页面置换算法。
物理页框地址 (PPN)：这是页表项中存储的物理页框的地址。它指示了虚拟页到物理页的映射关系。

Sv39 页表的页表项标志位允许操作系统和硬件实现对虚拟内存的细粒度控制和保护。不同的标志位组合可以实现不同级别的内存保护和权限控制，从而提高系统的安全性和可用性。例如，有效位、写入位、用户位和执行位的不同组合可以实现不同级别的内存保护，使操作系统可以将不同的内存区域分配给用户态和内核态，并设置不同的权限。已访问位和已修改位则用于实现页面置换算法，帮助操作系统决定哪些页面应该被置换出去，以优化内存利用率。全局位可以用于标识全局共享的页，从而节省 TLB 缓存空间。物理页框地址是页表项的核心，它建立了虚拟地址到物理地址的映射关系，使虚拟内存管理成为可能。

缺页相关问题

请问哪些异常可能是缺页导致的？

缺页异常是由于进程访问的页面不在页表中或者在页表中无效而引发的异常。以下这些异常可能是因为缺页导致的：

Load Page Fault（Load 异常）：当进程试图读取一个不在页表中或者无效的页面时，会引发 Load Page Fault 异常。在 RISC-V 中，这个异常对应的异常代码是 5。
Store Page Fault（Store 异常）：当进程试图写入一个不在页表中或者无效的页面时，会引发 Store Page Fault 异常。在 RISC-V 中，这个异常对应的异常代码是 7。
Instruction Page Fault（指令页异常）：当进程试图执行一个不在页表中或者无效的页面上的指令时，会引发 Instruction Page Fault 异常。在 RISC-V 中，这个异常对应的异常代码是 12。

发生缺页时，描述相关的重要寄存器的值（lab2 中描述过的可以简单点）。

sepc（Exception Program Counter）：trap 发生时会将当前指令的下一条指令地址写入其中，用于 trap 处理完成后返回。
stval（Machine Trap Value）：mtval 寄存器包含导致异常的原因，即导致异常的指令的具体信息。例如，如果是缺页异常，那么 mtval 寄存器包含导致缺页异常的虚拟地址。
scause: 中断/异常发生时， CSR 寄存器 scause 中会记录其信息， Interrupt 位记录是中断还是异常， Exception Code 记录中断/异常的种类。
sstatus: 记录处理器当前状态，其中 SPP 段记录当前特权等级。
stvec: 记录处理 trap 的入口地址，现有两种模式 Direct 和 Vectored 。
sscratch: 其中的值是指向hart相关的S态上下文的指针，比如内核栈的指针。

以下行为的好处？

缺页有两个常见的原因，其一是 Lazy 策略，也就是直到内存页面被访问才实际进行页表操作。比如，一个程序被执行时，进程的代码段理论上需要从磁盘加载到内存。但是 os 并不会马上这样做，而是会保存 .text 段在磁盘的位置信息，在这些代码第一次被执行时才完成从磁盘的加载操作。

Lazy Loading 策略有以下好处：

减少初始化开销：Lazy Loading 允许操作系统在程序启动时只加载必需的页面，而不是一次性加载整个程序。这可以减少启动时间和初始化开销，因为不需要将整个程序加载到内存中。
节省内存：Lazy Loading 策略避免了不必要的内存占用。如果程序的某些部分从不被访问，那么它们就不会被加载到内存中，从而节省了内存资源。
提高响应速度：通过仅在需要时加载页面，Lazy Loading 可以提高系统的响应速度。只有当程序访问某个页面时，操作系统才会执行磁盘加载操作，而不会在程序启动时浪费时间加载可能永远不会被访问的内容。
更好的磁盘利用率：Lazy Loading 允许操作系统将程序的不同部分分散在磁盘上，根据需要加载。这可以提高磁盘利用率，因为不需要在磁盘上为整个程序分配连续的空间。

请问处理 10G 连续的内存页面，需要操作的页表实际大致占用多少内存 (给出数量级即可)？

此外 COW(Copy On Write) 也是常见的容易导致缺页的 Lazy 策略，这个之后再说。其实，我们的 mmap 也可以采取 Lazy 策略，比如：一个用户进程先后申请了 10G 的内存空间，然后用了其中 1M 就直接退出了。按照现在的做法，我们显然亏大了，进行了很多没有意义的页表操作。

处理 10GB 连续的内存页面所需的页表实际上占用的内存量取决于操作系统的页表结构和管理策略。在 RISC-V 的页表结构中，一个页表项（Page Table Entry，PTE）通常占据 8 字节（64 位系统），其中包括物理页框号和一些标志位。让我们假设一个 PTE 占用 8 字节。

为了估算 10GB 连续内存页面所需的页表实际占用内存量，我们可以按照以下步骤进行计算：

首先，将 10GB 转换为字节数。1GB 等于 1,073,741,824 字节，所以 10GB 等于 10 * 1,073,741,824 = 10,737,418,240 字节。
然后，计算每个页面表项覆盖的内存范围。假设每个页面表项管理 4KB（4 * 1024 字节）的内存页面。
计算需要多少个页面表项来管理 10GB 的内存。这可以通过将 10GB 除以每个页面表项管理的内存范围来实现。
最后，将所需的页面表项数量乘以每个 PTE 的大小来估算所需的总内存量。

让我们进行具体计算：

内存大小：10,737,418,240 字节
每个页面表项管理的内存范围：4KB = 4 * 1024 字节
需要的页面表项数量：10,737,418,240 字节 / 4KB = 2,621,440 个页表项

假设每个页表项占用 8 字节，则需要的总内存量为：

2,621,440 个页表项 * 8 字节/页表项 = 20,971,520 字节

所以，处理 10GB 连续的内存页面所需的页表实际占用内存量约为 20,971,520 字节，或者大约 20MB。这只是一个估算，实际内存占用可能会因操作系统的管理策略和对齐等因素而有所不同。

请简单思考如何才能在现有框架基础上实现 Lazy 策略，缺页时又如何处理？描述合理即可，不需要考虑实现。

要在现有框架基础上实现 Lazy 策略，可以采取以下简单思路：

延迟加载（Lazy Loading）：在用户进程请求内存映射时，不立即将整个内存区域加载到物理内存中。而是仅创建虚拟内存映射和页表项，记录对应的磁盘位置等信息。
缺页处理（Page Fault Handling）：当用户进程访问虚拟内存中的某个尚未加载的内存页面时，会触发缺页异常。在缺页异常处理程序中，操作系统会根据页表中的磁盘位置信息，将相应的磁盘数据加载到物理内存中，并更新页表项，使其指向新加载的物理页面。
惰性加载（Demand Paging）：为了提高性能，可以采用惰性加载策略，即只加载实际被访问的内存页面，而不是一次性加载整个区域。这可以通过在缺页处理程序中进行懒加载操作来实现。
内存回收（Memory Reclamation）：当系统内存不足时，操作系统可以选择回收一些不常访问的内存页面，将其写回磁盘，并更新页表项为无效。这需要根据页面访问模式和策略来确定哪些页面可以被回收。
性能优化：为了提高性能，可以采用预读取（Prefetching）策略，即在缺页处理时，不仅加载当前访问的页面，还预先加载相邻的页面，以减少未来可能的缺页次数。

此时页面失效如何表现在页表项 (PTE) 上？

缺页的另一个常见原因是 swap 策略，也就是内存页面可能被换到磁盘上了，导致对应页面失效。

Dirty bit (D 位)：当页面被修改并且尚未写回到主存时，该位会被设置为 1。如果页面已经被换出到磁盘上，D 位将保持为 1，以指示页面数据已过期。

Valid bit (V 位)：当页面在主存中有效时，V 位被设置为 1。如果页面被换出到磁盘上，V 位将被清除为 0，表示该页无效。

通过检查页表项的 D 位和 V 位，操作系统可以确定页面是否需要从磁盘重新加载到内存中。如果 D 位为 1，说明页面需要写回到主存，在将其置为有效之前，必须将页数据从磁盘读取到内存中。如果 V 位为 0，说明页面当前无效，需要将其从磁盘加载到内存中，并将 V 位设置为 1，表示页面有效。

双页表与单页表

为了防范侧信道攻击，我们的 os 使用了双页表。但是传统的设计一直是单页表的，也就是说，用户线程和对应的内核线程共用同一张页表，只不过内核对应的地址只允许在内核态访问。请结合课堂知识回答如下问题：(备注：这里的单/双的说法仅为自创的通俗说法，并无这个名词概念，详情见 KPTI )

单页表情况下，如何更换页表？

在单页表情况下，页表的更换通常是由操作系统的上下文切换来触发的。当从用户态切换到内核态或从一个进程切换到另一个进程时，操作系统会根据相应的上下文信息加载不同的页表，实现页表的更换。

单页表情况下，如何控制用户态无法访问内核页面？（tips:看看第一题最后一问）

设置页面权限：内核页面通常会被设置为只能在内核态下访问（例如，设置 PTE_U 位为 0），这样用户态无法访问内核页面。
操作系统权限：操作系统内核态拥有较高的权限，可以通过特权级别或访问控制机制来确保用户态无法直接访问内核页面。用户程序只能通过系统调用进入内核态，并在内核态下由操作系统执行，从而实现对内核页面的访问控制。

单页表有何优势？（回答合理即可）

单页表的主要优势在于简化了地址转换过程，减少了内存访问的开销。由于用户线程和内核线程共享同一张页表，不需要在上下文切换时频繁切换页表，这可以提高地址转换的效率。此外，单页表还可以节省内存，因为不需要为每个用户线程分配独立的页表。

双页表实现下，何时需要更换页表？假设你写一个单页表操作系统，你会选择何时更换页表（回答合理即可）？

在双页表实现下，页表的更换通常在发生上下文切换时需要。当从用户态切换到内核态或从一个进程切换到另一个进程时，需要加载相应的页表，以确保正确的地址转换。如果操作系统采用了每个进程独立的页表，那么在进程切换时需要更换页表。

如果我写一个单页表操作系统，我会选择在发生进程切换时更换页表，因为这是最频繁的上下文切换情况之一。在其他情况下，如从用户态切换到内核态，可能不需要更换整张页表，而只需修改页表项的权限位来实现访问控制。这样可以减少页表更换的开销，提高性能。

附录

修改user项目中的makefile，删除ch4_

uCore 实验第 3 章 - 多道程序与分时多任务

Sat, 02 Sep 2023 16:03:02 +0000

// 启动时初始化进程表
void proc_init(void)
{
    struct proc *p;
    for (p = pool; p < &pool[NPROC]; p++) {
        p->state = UNUSED;
        // p - pool 是 p 指向的 proc 在 pool 中的下标，因此 p - pool 变化情况是 0, 1, 2, ..., NPROC - 1
        p->kstack    = (uint64)kstack[p - pool];
        p->ustack    = (uint64)ustack[p - pool];
        p->trapframe = (struct trapframe *)trapframe[p - pool];
        /*
		* LAB1: you may need to initialize your new fields of proc here
		*/
    }
    idle.kstack  = (uint64)boot_stack_top;
    idle.pid     = 0;
    current_proc = &idle;
}

p - pool 表示什么？假设我们有一个名为 pool 的数组，其中包含了多个类型为 struct proc 的元素，并且有一个指针 p 指向其中的某个元素。当 p 指向 pool 数组的第一个元素时，p - pool 的结果将是 0，因为指针相对于数组首地址的偏移量为 0。当 p 指向 pool 数组的第二个元素时，p - pool 的结果将是 1，因为指针相对于数组首地址的偏移量为 1。以此类推，当 p 指向 pool 数组的第 N 个元素时，p - pool 的结果将是 N-1，因为指针相对于数组首地址的偏移量为 N-1。总结来说，如果 p 是指向 pool 数组中第 N 个元素的指针，那么 p - pool 的结果将是 N-1。

原调度函数每次都会从 pool 数组的第一个元素开始遍历，这样会导致每次都是从第一个进程开始运行，而不是从上次运行的进程开始运行。需要修改为如下：

// 调度程序永不返回。它循环执行以下操作：
//  - 选择要运行的进程。
//  - 切换以启动运行该进程。
//  - 最终，该进程通过切换将控制权
//    传递回调度程序。
void scheduler(void)
{
    struct proc *p;
    struct proc *last_checked_proc = pool; // 初始化指针为 pool

    for (;;) {
        for (p = last_checked_proc; p < &pool[NPROC];
             p++) { // 将 p 初始化为 last_checked_proc
            if (p->state == RUNNABLE) {
                /*
                * LAB1：你可能需要在这里初始化进程的起始时间
                */
                p->state     = RUNNING;
                current_proc = p;
                swtch(&idle.context, &p->context);
            }
        }
        last_checked_proc = pool + 1; // 更新 last_checked_proc 的值为下一个位置
    }
}

LAB1

---
 os/loader.c           |   5 +-
 os/proc.c             |  15 +-
 os/proc.h             |  23 +-
 os/syscall.c          |  55 ++++-
 os/syscall_ids.h      |   5 +-
 os/timer.h            |   2 +
 9 files changed, 374 insertions(+), 291 deletions(-)

diff --git a/os/loader.c b/os/loader.c
index b45e85d..b21b0a4 100644
--- a/os/loader.c
+++ b/os/loader.c
@@ -1,6 +1,7 @@
 #include "loader.h"
 #include "defs.h"
 #include "trap.h"
+#include <string.h>
 
 static uint64  app_num;
 static uint64 *app_info_ptr;
@@ -49,8 +50,10 @@ int run_all_app()
         trapframe->sp  = (uint64)p->ustack + USER_STACK_SIZE;
         p->state       = RUNNABLE;
         /*
-		* LAB1: you may need to initialize your new fields of proc here
+		* LAB1: 初始化系统调用数以及进程开始时间
 		*/
+        memset(p->syscall_times, 0, MAX_SYSCALL_NUM * sizeof(uint32));
+        p->start_time = 0;
     }
     return 0;
 }
\ No newline at end of file
diff --git a/os/proc.c b/os/proc.c
index fee3886..0c69ae5 100644
--- a/os/proc.c
+++ b/os/proc.c
@@ -2,6 +2,7 @@
 #include "defs.h"
 #include "loader.h"
 #include "trap.h"
+#include "timer.h"
 
 struct proc pool[NPROC];
 char        kstack[NPROC][PAGE_SIZE];
@@ -33,9 +34,8 @@ void proc_init(void)
         p->kstack    = (uint64)kstack[p - pool];
         p->ustack    = (uint64)ustack[p - pool];
         p->trapframe = (struct trapframe *)trapframe[p - pool];
-        /*
-		* LAB1: you may need to initialize your new fields of proc here
-		*/
+        memset(p->syscall_times, 0, MAX_SYSCALL_NUM * sizeof(uint32));
+        p->start_time = 0;
     }
     idle.kstack  = (uint64)boot_stack_top;
     idle.pid     = 0;
@@ -47,6 +47,7 @@ int allocpid()
     static int PID = 1;
     return PID++;
 }
+
 // 在进程表中寻找一个未使用的进程。
 // 如果找到，则初始化在内核中运行所需的状态。
 // 如果没有空闲的进程，或者内存分配失败，则返回 0。
@@ -80,14 +81,18 @@ void scheduler(void)
 {
     struct proc *p;
     struct proc *last_checked_proc = pool; // 初始化指针为 pool
-
     for (;;) {
         for (p = last_checked_proc; p < &pool[NPROC];
              p++) { // 将 p 初始化为 last_checked_proc
             if (p->state == RUNNABLE) {
                 /*
-                * LAB1：你可能需要在这里初始化进程的起始时间
+                * LAB1：在这里初始化进程的开始时间
                 */
+                if (p->start_time == 0) {
+                    uint64 cycle = get_cycle();
+                    p->start_time =
+                        (cycle % CPU_FREQ) * MILLISECONDS_PER_SECOND / CPU_FREQ;
+                }
                 p->state     = RUNNING;
                 current_proc = p;
                 swtch(&idle.context, &p->context);
diff --git a/os/proc.h b/os/proc.h
index d208c5d..53576bf 100644
--- a/os/proc.h
+++ b/os/proc.h
@@ -3,7 +3,8 @@
 
 #include "types.h"
 
-#define NPROC (16)
+#define NPROC           (16)  // 最大进程数
+#define MAX_SYSCALL_NUM (500) // 最大系统调用数
 
 // Saved registers for kernel context switches.
 struct context {
@@ -42,14 +43,28 @@ struct proc {
     uint64            kstack;    // 进程内核栈虚拟地址 (内核页表)
     struct trapframe *trapframe; // 进程中断帧
     struct context    context; // 用于保存进程内核态的寄存器信息，进程切换时使用
-                               /*
-	* LAB1: you may need to add some new fields here
+    /*
+	* LAB1: 添加一些新的成员用于新的 sys_task_info 系统调用
 	*/
+    uint32 syscall_times[MAX_SYSCALL_NUM]; // 系统调用次数统计 TODO: 后续改为指针
+    uint64 start_time;                     // 进程开始运行时间
 };
 
 /*
-* LAB1: you may need to define struct for TaskInfo here
+* LAB1: 定义 TaskInfo 结构体
 */
+typedef enum {
+    UnInit,
+    Ready,
+    Running,
+    Exited,
+} TaskStatus;
+
+typedef struct {
+    TaskStatus status;
+    uint32     syscall_times[MAX_SYSCALL_NUM];
+    int        time; // 进程运行时间统计
+} TaskInfo;
 
 struct proc *curr_proc();
 void         exit(int);
diff --git a/os/syscall.c b/os/syscall.c
index 1cc5aeb..f54ed86 100644
--- a/os/syscall.c
+++ b/os/syscall.c
@@ -4,6 +4,7 @@
 #include "syscall_ids.h"
 #include "timer.h"
 #include "trap.h"
+#include "proc.h"
 
 uint64 sys_write(int fd, char *str, uint len)
 {
@@ -31,14 +32,46 @@ uint64 sys_sched_yield()
 uint64 sys_gettimeofday(TimeVal *val, int _tz)
 {
     uint64 cycle = get_cycle();
-    val->sec     = cycle / CPU_FREQ;
-    val->usec    = (cycle % CPU_FREQ) * MICROSECONDS_PER_SECOND / CPU_FREQ;
+    tracef("sys_gettimeofday cycle = %d", cycle);
+    val->sec  = cycle / CPU_FREQ;
+    val->msec = (cycle % CPU_FREQ) * MILLISECONDS_PER_SECOND / CPU_FREQ;
+    val->usec = (cycle % CPU_FREQ) * MICROSECONDS_PER_SECOND / CPU_FREQ;
     return 0;
 }
 
-/*
-* LAB1: you may need to define sys_task_info here
-*/
+/** 
+ * LAB1：此处定义 sys_task_info 函数
+ * 查询当前正在执行的任务信息，任务信息包括任务控制块相关信息（任务状态）、任务使用的系统调用次数、任务总运行时长。 
+ */
+int sys_task_info(TaskInfo *ti)
+{
+    struct proc *proc = curr_proc();
+    // TODO: proc 检查为空
+    for (int i = 0; i < MAX_SYSCALL_NUM; i++) {
+        ti->syscall_times[i] = proc->syscall_times[i];
+    }
+    uint64 cycle = get_cycle();
+    uint64 current_time =
+        (cycle % CPU_FREQ) * MILLISECONDS_PER_SECOND / CPU_FREQ;
+    infof("sys_task_info current_time = %d", current_time);
+    infof("proc->start_time = %d", proc->start_time);
+    infof("ti->time = %d", current_time - proc->start_time);
+
+    if (proc->state == RUNNING) {
+        ti->status = Running;
+    } else if (proc->state == RUNNABLE) {
+        ti->status = Ready;
+    } else if (proc->state == SLEEPING) {
+        ti->status = Ready;
+    } else if (proc->state == ZOMBIE) {
+        ti->status = Exited;
+    } else if (proc->state == UNUSED) {
+        ti->status = UnInit;
+    }
+
+    ti->time = current_time - proc->start_time;
+    return 0;
+}
 
 extern char trap_page[];
 
@@ -51,8 +84,9 @@ void syscall()
     tracef("syscall %d args = [%x, %x, %x, %x, %x, %x]", id, args[0], args[1],
            args[2], args[3], args[4], args[5]);
     /*
-	* LAB1: you may need to update syscall counter for task info here
+	* LAB1: 更新系统调用次数
 	*/
+    curr_proc()->syscall_times[id]++;
     switch (id) {
     case SYS_write:
         ret = sys_write(args[0], (char *)args[1], args[2]);
@@ -67,8 +101,15 @@ void syscall()
         ret = sys_gettimeofday((TimeVal *)args[0], args[1]);
         break;
     /*
-	* LAB1: you may need to add SYS_taskinfo case here
+	* LAB1: 在此处添加 SYS_task_info 的系统调用处理情况
 	*/
+    case SYS_task_info:
+        ret = sys_task_info((TaskInfo *)args[0]);
+        break;
+    case SYS_getpid:
+        infof("SYS_getpid %d", SYS_getpid);
+        ret = curr_proc()->pid;
+        break;
     default:
         ret = -1;
         errorf("unknown syscall %d", id);
diff --git a/os/syscall_ids.h b/os/syscall_ids.h
index 05a6cb9..3c1a5a9 100644
--- a/os/syscall_ids.h
+++ b/os/syscall_ids.h
@@ -277,9 +277,8 @@
 #define SYS_io_pgetevents          292
 #define SYS_rseq                   293
 #define SYS_kexec_file_load        294
-/*
-* LAB1: you may need to define SYS_task_info here
-*/
+// LAB1：添加 SYS_task_info 的系统调用号
+#define SYS_task_info          410
 #define SYS_pidfd_send_signal  424
 #define SYS_io_uring_setup     425
 #define SYS_io_uring_enter     426
diff --git a/os/timer.h b/os/timer.h
index c6ebd14..63ab45c 100644
--- a/os/timer.h
+++ b/os/timer.h
@@ -6,6 +6,7 @@
 #define TICKS_PER_SEC (100)
 // QEMU
 #define CPU_FREQ                (12500000)
+#define MILLISECONDS_PER_SECOND (1000)
 #define MICROSECONDS_PER_SECOND (1000000)
 
 uint64 get_cycle();
@@ -14,6 +15,7 @@ void   set_next_timer();
 
 typedef struct {
     uint64 sec;  // 自 Unix 纪元起的秒数
+    uint64 msec; // 毫秒数
     uint64 usec; // 微秒数
 } TimeVal;
 
-- 
2.34.1

问答作业

问题一

正确进入 U 态后，程序的特征还应有：使用 S 态特权指令，访问 S 态寄存器后会报错。请同学们可以自行测试这些内容（参考前三个测例，描述程序出错行为，同时注意注明你使用的 sbi 及其版本。

测试前三个测试用例指的是uCore-Tutorial-Code-2023S/user/src/ 目录下的三个bad测试用例，查看user项目的 Makefile 可以发现在编译时修改CHAPTER参数值为2_bad即可编译运行这些测试用例。

[rustsbi] RustSBI version 0.3.0-alpha.2, adapting to RISC-V SBI v1.0.0
.______       __    __      _______.___________.  _______..______   __
|   _  \     |  |  |  |    /       |           | /       ||   _  \ |  |
|  |_)  |    |  |  |  |   |   (----`---|  |----`|   (----`|  |_)  ||  |
|      /     |  |  |  |    \   \       |  |      \   \    |   _  < |  |
|  |\  \----.|  `--'  |.----)   |      |  |  .----)   |   |  |_)  ||  |
| _| `._____| \______/ |_______/       |__|  |_______/    |______/ |__|
[rustsbi] Implementation     : RustSBI-QEMU Version 0.2.0-alpha.2
[rustsbi] Platform Name      : riscv-virtio,qemu
[rustsbi] Platform SMP       : 1
[rustsbi] Platform Memory    : 0x80000000..0x88000000
[rustsbi] Boot HART          : 0
[rustsbi] Device Tree Region : 0x87000000..0x87000ef2
[rustsbi] Firmware Address   : 0x80000000
[rustsbi] Supervisor Address : 0x80200000
[rustsbi] pmp01: 0x00000000..0x80000000 (-wr)
[rustsbi] pmp02: 0x80000000..0x80200000 (---)
[rustsbi] pmp03: 0x80200000..0x88000000 (xwr)
[rustsbi] pmp04: 0x88000000..0x00000000 (-wr)
[TRACE 0]load app 0 at 0x0000000080400000
[TRACE 0]load app 1 at 0x0000000080420000
[TRACE 0]load app 2 at 0x0000000080440000
[INFO 0]start scheduler!
[ERROR 1]unknown trap: 0x0000000000000007, stval = 0x0000000000000000

[INFO 1]进程 1 以代码 -1 退出
IllegalInstruction in application, core dumped.
[INFO 2]进程 2 以代码 -3 退出
IllegalInstruction in application, core dumped.
[INFO 3]进程 3 以代码 -3 退出
[PANIC 3] os/loader.c:15: all apps over

第一个进程测试用例如下：

int main()
{
	int *p = (int *)0;
	*p = 0;
	return 0;
}

在您提供的代码中，将空指针分配给指针变量*p 后，试图对其进行解引用并将值 0 赋给该指针。由于用户模式下禁止直接访问物理内存，操作系统会检测到这个非法操作并触发异常。因此，该程序 IllegalInstruction in application, core dumped.

在 RISC-V 架构中，U 模式是最低的用户模式，用户程序无法直接访问物理内存或其他特权级别资源。这种限制是为了确保操作系统的安全性和稳定性。

第二个进程测试用例如下：

int main()
{
	asm volatile("sret");
	return 0;
}

试图使用汇编语言执行 sret 指令，该指令用于从中断或异常处理程序返回。由于用户模式下禁止直接访问特权级别寄存器，操作系统会检测到这个非法操作并触发异常。因此，该程序 IllegalInstruction in application, core dumped。

第三个进程测试用例如下：

int main()
{
	uint64 x;
	asm volatile("csrr %0, sstatus" : "=r"(x));
	return 0;
}

原因同上，试图使用汇编语言执行 csrr 指令，该指令用于从特权级别寄存器中读取值。由于用户模式下禁止直接访问特权级别寄存器，操作系统会检测到这个非法操作并触发异常。因此，该程序 IllegalInstruction in application, core dumped。

在操作系统代码中，触发异常后会进入void usertrap() 函数，该函数会根据 scause 寄存器的值判断异常类型，用例中的结果进入了case IllegalInstruction，其中 IllegalInstruction = 2。我们查阅手册 riscv-privileged.pdf ，可以查到 IllegalInstruction 的值为 2，与预期相符。

问题二

请结合用例理解 trampoline.S 中两个函数 userret 和 uservec 的作用，并回答如下几个问题：

L79: 刚进入 `userret` 时，`a0`、`a1` 分别代表了什么值。

在进入userret函数时，a0和a1分别代表以下值：

a0: TRAPFRAME 的地址，指向当前进程的陷阱帧（trapframe）结构体。
a1: 用户页表的地址，即进程的页表（pagetable）。这个地址会被写入到satp寄存器中，用于切换到用户模式的页表。

L87-L88: `sfence` 指令有何作用？为什么要执行该指令，当前章节中，删掉该指令会导致错误吗？

csrw satp, a1
sfence.vma zero, zero

sfence指令（Store Fence）的作用是确保之前的存储操作完成，并且对其他处理器上的核心可见。

执行sfence指令的主要目的是为了保证内存访问的顺序性和一致性。在多核处理器系统中，不同的核心可能会有自己的缓存，当一个核心修改了共享内存中的数据时，为了保证其他核心能够看到这个修改，需要使用sfence指令来刷新缓存并将修改写回共享内存。

在代码中，sfence指令被用于确保对用户页表的修改对其他处理器上的核心可见。因为目前我只使用了单核处理器，所以不会出现多核处理器的情况，因此sfence指令的作用是确保对用户页表的修改对当前核心可见。

因此，当前章节中，删掉该指令不会导致错误。

L96-L125: 为何注释中说要除去 `a0`？哪一个地址代表 `a0`？现在 `a0` 的值存在何处？

# restore all but a0 from TRAPFRAME
ld ra, 40(a0)
ld sp, 48(a0)
ld t5, 272(a0)
ld t6, 280(a0)

a0 是保存在 sscratch 寄存器中的，首先，该代码通过 ld 指令从 TRAPFRAME 中加载各个寄存器的值。然后，这些值被存储在相应的寄存器中，以便在恢复用户上下文时使用。

接下来，代码使用 csrrw 指令将 sscratch 寄存器的值与 a0（即 TRAPFRAME）进行交换。这样做是为了将用户的 a0（TRAPFRAME）保存在 sscratch 寄存器中，以便后续步骤可以正确地恢复用户上下文。

最后，通过 sret 指令返回到用户模式，并将控制权交给用户代码。在执行 sret 指令后，处理器将根据用户上下文中的 sepc 寄存器的值跳转到用户代码的指令地址。返回的同时，处理器还会自动恢复 sstatus 寄存器的值，以确保正确的特权级别和中断状态。

`userret`：中发生状态切换在哪一条指令？为何执行之后会进入用户态？

在userret函数中，发生状态切换的指令是sret指令。

sret指令用于从内核模式切换到用户模式，并将控制权交给用户代码。执行sret指令后，处理器会根据用户上下文中的sepc寄存器的值跳转到用户代码的指令地址。

执行sret指令之后进入用户态的原因是，该指令会自动恢复sstatus寄存器的值，以确保正确的特权级别和中断状态。当sret指令执行后，处理器将从内核态切换回用户态，程序将继续执行用户代码。这意味着userret函数成功完成了从内核切换到用户模式的过程。

L29：执行之后，a0 和 sscratch 中各是什么值，为什么？

csrrw a0, sscratch, a0

在执行指令后，a0和sscratch中的值发生了互换。

假设原始a0寄存器中的值为 X，而sscratch寄存器中的值为 Y。执行csrrw a0, sscratch, a0指令后，a0寄存器中的值变为 Y，而sscratch寄存器中的值变为 X。

这是因为csrrw指令是一个特权指令，用于将某个 CSR（Control and Status Register）的值读取到目标寄存器，然后将目标寄存器的值写回到该 CSR 中。在这里，csrrw a0, sscratch, a0指令将sscratch寄存器的值读取到a0寄存器中，同时将a0寄存器中的值写回到sscratch寄存器中，从而实现了两者之间的数据交换。

L32-L61: 从 trapframe 第几项开始保存？为什么？是否从该项开始保存了所有的值，如果不是，为什么？


sd ra, 40(a0)
sd sp, 48(a0)
...
sd t5, 272(a0)
sd t6, 280(a0)

进入 S 态是哪一条指令发生的？

L75-L76: `ld t0, 16(a0)` 执行之后，`t0`中的值是什么，解释该值的由来？

ld t0, 16(a0)
jr t0

ld t0, 16(a0)就是从 trapframe 中恢复 t0寄存器值，t0保存了kernel_trap的入口地址。使用 jr t0，就跳转到了我们早先设定在 trapframe->kernel_trap 中的地址，也就是 trap.c 之中的 usertrap 函数。这个函数在 main 的初始化之中已经调用了。

uCore 实验第 2 章 - 批处理系统

Thu, 31 Aug 2023 23:16:38 +0000

flowchart TB
    subgraph entry.S
        _entry[_entry]
    end
    subgraph link_app.S
        _app_num[_app_num]
    end
    subgraph main.c
        main[main]
    end
    subgraph loader.c
        loader_init[loader_init]
        run_next_app[run_next_app]
        load_app[load_app]
    end

    _entry --> main
    main --> loader_init
    main --> run_next_app
    run_next_app --> load_app
    loader_init --> _app_num

QEMU启动RISC-V架构OpenEuler并配置OSC环境

Sun, 23 Jul 2023 19:28:29 +0000

基于Ubuntu 18.04，QEMU 8.0.2，OpenEuler 22.09

安装QEMU

安装基础编译工具

sudo apt install build-essential autoconf automake autotools-dev pkg-config bc curl \
                 gawk git bison flex texinfo gperf libtool patchutils mingw-w64 libmpc-dev \
                 libmpfr-dev libgmp-dev libexpat-dev libfdt-dev zlib1g-dev libglib2.0-dev \
                 libpixman-1-dev libncurses5-dev libncursesw5-dev meson libvirglrenderer-dev libsdl2-dev  -y

sudo add-apt-repository ppa:deadsnakes/ppa
sudo apt install python3.8 python3-pip  -y
sudo apt install -f
pip3 install meson

下载QEMU

建立文件夹用于编译：

cd && mkdir -p qemu-build

建立文件夹用于安装：

cd && mkdir -p /home/user/program/riscv64-qemu

可登录官网将版本号换成最新版本即可：

cd qemu-build && wget  "https://download.qemu.org/qemu-8.0.2.tar.xz"

tar -xf qemu-8.0.2.tar.xz --strip-components=1

安装QEMU

cd qemu-build && ./configure --target-list=riscv32-softmmu,riscv32-linux-user,riscv64-linux-user,riscv64-softmmu \
               --enable-kvm --enable-sdl \
               --prefix=/home/user/program/riscv64-qemu

make install -j $(nproc)

配置环境变量

echo 'export QEMU_HOME=/home/user/program/riscv64-qemu' >> ~/.bashrc && echo 'export PATH=$QEMU_HOME/bin:$PATH' >> ~/.bashrc

source ~/.bashrc

下载 OpenEuler RISC-V 系统镜像

建立目录：

cd && mkdir -p /home/user/openeuler

根据自己的用户名修改user

下载OpenEuler 22.09版本，下载目录下所有文件/home/user/openeuler。如需下载其他版本请进入其他目录选择下载即可。

也可以根据自己的情况进入镜像站列表选择下载速度更快的镜像站下载

最新的23.03版本需要在中科院镜像站下载

文件说明：

fw_payload_oe_qemuvirt.elf: 利用 openSBI 将 kernel-5.10 的 image 作为 payload 所制作的 QEMU 启动所需文件
openEuler-22.09-qemu-xfce.qcow2.tar.zst: openEuler RISC-V QEMU GUI 镜像压缩包
preview_start_vm_xfce.sh: GUI 虚拟机启动脚本
openeuler-22.09-qemu.qcow2.tar.zst: openEuler RISC-V QEMU headless 镜像压缩包
preview_start_vm.sh: headless 虚拟机启动脚本

解压：

 sudo apt-get install zstd

 tar -I 'zstdmt' -xvf openEuler-22.09-riscv64-qemu.qcow2.tar.zst

执行启动脚本

chmod +x preview_start_vm.sh

bash preview_start_vm.sh

登录系统

用户名: root
默认密码: openEuler12#$

openEuler 22.09
Kernel 5.10.0 on an riscv64

4penEuler-riscv6
 login: openEuler 22.09
Kernel 5.10.0 on an riscv64

openEuler-riscv64 login: root
Password: 


Welcome to 5.10.0

System information as of time:   Mon Jul  3 07:52:19 PM CST 2023

System load:   0.17
Processes:   117
Memory used:   .6%
Swap used:   0.0%
Usage On:   6%
Users online:   1


[root@openEuler-riscv64 ~]# ls
[root@openEuler-riscv64 ~]# pwd

远程登录系统

ssh -p 12055 root@localhost

配置系统

以下操作均在root用户下执行，如果切换了用户会有提示。因为系统初始状态没有普通用户，也没有sudo，所以需要使用root完成一些基础配置。

修改root密码

原密码太复杂，修改简单密码

passwd root
# 输入两次密码

添加普通用户

# 添加用户 user
useradd -s /bin/bash -d /home/user -m user

passwd user
# 输入两次密码

# 添加管理员权限
usermod -aG wheel user

修改时间

echo "NTP=ntp.aliyun.com" >> /etc/systemd/timesyncd.conf

systemctl restart systemd-timesyncd.service

查看timesyncd运行状态：

systemctl status systemd-timesyncd.service

date命令可查看当前系统时间。验证是否配置成功。

时间务必正确设置，错误的时间会影响诸如https的TLS认证等过程。

配置DNS

vim /etc/resolv.conf
nameserver 119.29.29.29

配置软件包源

配置文件为 /etc/yum.repos.d/openEuler.repo 下

mv /etc/yum.repos.d/openEuler.repo  /etc/yum.repos.d/openEuler.repo.bk && sudo bash -c "cat << EOF > /etc/yum.repos.d/openEuler.repo
# just for test
[mainline]
name=mainline
baseurl=https://mirror.iscas.ac.cn/openeuler-sig-riscv/openEuler-RISC-V/preview/openEuler-22.09-V1-riscv64/repo/22.09/
enabled=1
gpgcheck=0
# just for test
[epol]
name=epol
baseurl=https://mirror.iscas.ac.cn/openeuler-sig-riscv/openEuler-RISC-V/preview/openEuler-22.09-V1-riscv64/repo/22.09/
enabled=1
gpgcheck=0
[extra]
name=extra
baseurl=https://mirror.iscas.ac.cn/openeuler-sig-riscv/openEuler-RISC-V/preview/openEuler-22.09-V1-riscv64/repo/extra/
enabled=1
gpgcheck=0
EOF"

需要注意的是，因为OpenEuler还在快速发展中，镜像地址可能会发生变化，所以需确认地址是否能够正常访问，如无法访问会导致404错误

[repoid]中的repoid为软件仓库（repository）的ID号，所有.repo配置文件中的各repoid不能重复，必须唯一。示例中repoid设置为base。 name为软件仓库描述的字符串。 baseurl为软件仓库的地址。 enabled为是否启用该软件源仓库，可选值为1和0。默认值为1，表示启用该软件源仓库。 gpgcheck可设置为1或0，1表示进行gpg（GNU Private Guard）校验，0表示不进行gpg校验，gpgcheck可以确定rpm包的来源是有效和安全的。 gpgkey为验证签名用的公钥。

磁盘扩容

在宿主机上安装 qemu-img 工具:

apt install qemu-utils

在 openEuler RISC-V 虚拟机上安装 growpart 工具:

dnf install cloud-utils-growpart

关闭QEMU虚拟机
把 qcow2 文件的容量加200GB：

$ qemu-img resize *.qcow2 +200G
Image resized.
$ qemu-img info *.qcow2
image: openEuler-preview.riscv64.qcow2
file format: qcow2
virtual size: 220 GiB 
disk size: 9.58 GiB
cluster_size: 65536
Format specific information:
    compat: 1.1
    compression type: zlib
    lazy refcounts: false
    refcount bits: 16
    corrupt: false
    extended l2: false

QEMU 启动 openEuler RISC-V。

启动以后，我们先看看分区情况：可以看到根目录对应的分区只使用了 10G。

[root@openEuler-RISCV-rare ~]# lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
vda    254:0    0  220G  0 disk
└─vda1 254:1    0   10G  0 part /

扩展分区 vda1，执行

growpart /dev/vda1

执行 lsblk 可以看到 / 所在的 vda1 分区已经扩展到了预期大小

[root@openEuler-RISCV-rare ~]# growpart /dev/vda 1
CHANGED: partition=1 start=2048 old: size=20969472 end=20971520 new: size=419428319 end=419430367
[root@openEuler-RISCV-rare ~]# lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
vda    254:0    0  220G  0 disk
└─vda1 254:1    0  220G  0 part /

扩展文件系统：

resize2fs /dev/vda1

BUG

network backend ‘user‘ is not compiled into this binary

git clone https://gitlab.freedesktop.org/slirp/libslirp.git

http://security.ubuntu.com/ubuntu/pool/main/libs/libslirp/libslirp-dev_4.1.0-2ubuntu2.2_amd64.deb

sudo apt-get install libslirp-dev

重新编译QEMU：

cd qemu-build && rm -rf build

cd qemu-build && ./configure --target-list=riscv32-softmmu,riscv32-linux-user,riscv64-linux-user,riscv64-softmmu \
               --enable-kvm --enable-sdl --enable-slirp\
               --prefix=/home/user/program/riscv64-qemu

make install -j $(nproc)

参考文档

RISC-V/doc/tutorials/vm-qemu-oErv.md at master · openeuler-mirror/RISC-V · GitHub

openEuler 22.09技术白皮书

ZH-The RISC-V Instruction Set Manual Volume 2-特权级架构

Thu, 22 Sep 2022 09:37:54 +0000

Introduction

Document Version 20211203

Control and Status Registers (CSRs)

Machine-Level ISA, Version 1.12

本章介绍了机器模式（M-mode）中可用的机器级操作，这是 RISC-V 系统中最高权限的模式。M 模式用于对硬件平台的低级访问，是复位时进入的第一个模式。M 模式也可以用来实现那些在硬件中直接实现过于困难或成本高昂的功能。RISC-V 的机器级 ISA 包含一个共同的核心，根据支持的其他权限级别和硬件实现的其他细节来扩展。

Machine-Level CSRs

除了本节中描述的机器级 CSRs 外，M-mode 代码还可以访问较低特权级别的所有 CSRs。

Machine ISA Register `misa`

misa CSR 是 WARL 读写寄存器，报告硬件 (hart) 支持的 ISA。该寄存器在任何实现中都必须是可读的，但是可以返回零值以指示未实现 misa 寄存器，这就需要通过一个单独的非标准机制确定 CPU 功能。

Responsive Image

MXL（机器 XLEN）字段编码本机基本整数 ISA 宽度，如表 3.1 所示。MXL 字段在支持多个基本 ISA 宽度的实现中可能是可写的。M-mode 下的有效 XLEN, MXLEN，由 MXL 的设置给出，如果 misa 为零，则有一个固定的值。重置时，MXL 字段始终设置为最广泛支持的 ISA 变种。

Responsive Image

misa CSR 为 MXLEN 位宽。如果从 misa 读取的值不为零，该值的 MXL 字段总是表示当前的 MXLEN。如果对 misa 的写操作导致 MXLEN 发生更改，则 MXL 的位置将以新的宽度移动到 misa 的最高有效两位。

可以使用返回的 misa 值的符号上的分支，以及可能在符号上左移一个分支和第二个分支，来快速确定基本宽度。这些检查可以用汇编代码编写，而无需知道机器的寄存器宽度（XLEN）。基本宽度由 XLEN = 2^(MXL + 4) 给出。如果 misa 为零，则可以通过将立即数 4 放置在一个寄存器中，然后一次将寄存器左移 31 位来找到基本宽度。如果在一次移位后为零，则该机器为 RV32。如果两次移位后为零，则机器为 RV64，否则为 RV128。

Extensions 字段编码了目前存有的标准扩展，其每个 bit 都对应了字母表中的一个字母（bit 0 编码扩展“A”是否存在，bit 1 编码扩展“B”是否存在… 直至 bit 25 编码“Z”）。如果基础 ISA 是 RV32I、RV64I 或 RV128I，则置位“I”bit，否则如果基础 ISA 是 RV32E，则置位“E”bit。

Extensions 字段是一个能包含可写位的 WARL 字段（如果实现允许修改所支持的 ISA）。

复位（reset）时，Extensions 应包含所支持扩展的最大集，如果 E 和 I 都可用，则优先选择 I。

在通过清除 misa 中相应 bit 来禁止一个标准扩展时，由该扩展所定义或修改的指令和 CSR 将恢复为该扩展未实现时的定义，或者保留行为（revert to their defined or reserved behaviors as if the extension is not implemented）。

RV128 base ISA 的设计尚未完工，尽管预计本 specification 中大部分的剩余部分都将适用于 RV128，但本版本的文档仅关注 RV32 和 RV64。

如果支持用户模式（user mode），则将“U”bit 置位；如果支持主管模式（supervisor mode），则将“S”bit 置位。

如果存在任何非标准扩展（non-standard extensions），则将“X”bit 置位。

Responsive Image

“E”位是只读的。除非将 misa 硬连线为零，否则“E”位始终读取为“I”位的补码（补集？）。同时支持 RV32E 和 RV32I 的实现可以通过清除“I”位来选择 RV32E。

如果 ISA 功能 x 依赖 ISA 功能 y，则尝试启用功能 x 但禁用功能 y 会导致两个功能都被禁用。例如，设置“F” = 0 和“D” = 1 会导致同时清除“F”和“D”。

具体实现可能会在 2 或多个 misa 字段的集体设置上施加额外约束，此时将它们的集体看作是一个 WARL 字段。试图向其中写入一个不支持的组合会导致这些 bits 被置为某个支持的组合。

写 misa 可能会增加 IALIGN，例如，通过禁用 C 扩展。如果要写入 misa 的指令增加了 IALIGN，而后一条指令的地址未按 IALIGN 位对齐，则将抑制对 misa 的写入，从而使 misa 保持不变。

在软件启用一个之前被禁用的扩展时，除该扩展另有规定（specified），否则所有单独与该扩展有关的状态都将是未指定的（unspecified）。

Machine Vendor ID Register `mvendorid`

mvendorid CSR 是一个 32 位只读寄存器，提供内核供应商的 JEDEC 制造商 ID。此寄存器在任何实现中都必须是可读的，但可以返回 0，表示该字段未实现或这是非商业实现。

Responsive Image

JEDEC 制造商 ID 通常编码为单字节连续的 0x7f 代码的序列，以不等于 0x7f 的单字节 ID 终止，并且在每个字节的最高有效位中带有奇校验位。mvendorid 在 Bank 字段中编码单字节的连续代码，并在 Offset 字段中编码最后一个字节，丢弃奇偶校验位。例如，JEDEC 制造商 ID 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x8a（十二个连续代码，后跟 0x8a）将在 mvendorid 字段中编码为 0x60a。

译者注：JEDEC 固态技术协会（JEDEC Solid State Technology Association）是固态及半导体工业界的一个标准化组织，它由约 300 家公司成员组成，约 3300 名技术人员通过 50 个不同的委员会运作，制定固态电子方面的工业标准。JEDEC 曾经是电子工业联盟（EIA）的一部分：联合电子设备工程委员会（Joint Electron Device Engineering Council，JEDEC）。该协会制定了一个制造商标识码的标准：Standard Manufacturer’s Identification Code，通过读取mvendorid寄存器值，查阅该标准即可确定制造商。

注：用 JEDEC 的话来说，Bank 编号比 Continuation 的数量大 1；因此，mvendorid Bank 字段编码的值比 JEDEC Bank 编号小一。

注：以前，供应商 ID 是 RISC-V 基金会分配的编号，但这与 JEDEC 在维护制造商 ID 标准方面的工作重复。在撰写本文时，向 JEDEC 注册制造商 ID 的一次性费用为 500 美元。

Machine-Mode Privileged Instructions

Environment Call and Breakpoint

Trap-Return Instructions

Wait for Interrupt

等待中断指令 (WFI) 为实现提供了一个提示，即当前的 hart 可以停止，直到需要服务中断。WFI 指令的执行也可以用来通知硬件平台合适的中断应该优先路由到这个 hart。WFI 在所有特权模式下都可用，并且可用于 U 模式 (可选地)。当 mstatus 中的 TW = 1 时，该指令可能会引发非法指令异常，如第 3.1.6.5 节所述。

Responsive Image

如果在 hart 停止时存在或稍后出现启用的中断，则中断 trap 将在以下指令上执行，即在 trap 处理程序中恢复执行并且 mepc = pc + 4。

构建和测试 RISC-V 架构下启用 ACPI 的内核

Tue, 12 Jul 2022 15:06:51 +0000

参考自PoC : How to build and test ACPI enabled kernel · riscv-non-isa/riscv-acpi Wiki

准备环境及工具链

安装 RISC-V 工具链，需下载原发行版。好在 apt 可以安装。

如果报错：riscv64-linux-gnu-gcc: error: unrecognized command line option ‘-mno-relax’; did you mean ‘-Wno-vla’?，多半是工具链原因，请按照以下方法安装！！！
```
sudo apt remove gcc-riscv64-linux-gnu
sudo apt install gcc-8-riscv64-linux-gnu
```

安装必要的三方库，以下为Ubuntu下的命令，其他平台可以参考这个文档。

sudo apt install autoconf automake autotools-dev curl libmpc-dev libmpfr-dev libgmp-dev \
                gawk build-essential bison flex texinfo gperf libtool patchutils bc \
                zlib1g-dev libexpat-dev git

下载源码

可能无法一次搭建成功，一些环境变量会经常用到，所以干脆把所有环境变量放到.bashrc。

vim ~/.bashrc
# 添加以下内容
export WORK_DIR=~/riscv64-acpi
export GCC5_RISCV64_PREFIX=riscv64-unknown-elf-
export MAINSPACE=~/riscv64-acpi/tianocore
export PACKAGES_PATH=$MAINSPACE/edk2:$MAINSPACE/edk2-platforms
export EDK_TOOLS_PATH=$MAINSPACE/edk2/BaseTools

首先，创建一个工作目录，我们将在其中下载并构建所有源代码。

source ~/.bashrc
WORK_DIR=$PWD/riscv64-acpi
mkdir -p $WORK_DIR
cd $WORK_DIR

然后下载所有需要的源，它们是：qemu、opensbi、edk2、edk2-platforms、linux。

下载地址更换成了加速镜像源，原来地址下载太慢，容易中断。下载地址更换成了加速镜像源，原来地址下载太慢，容易中断。有两个项目包含子模块，下载容易出错，所以--depth=1舍弃了多余的提交记录。

git clone --branch dev-upstream  https://hub.fastgit.xyz/ventanamicro/qemu.git qemu
git clone --branch dev-upstream  https://hub.fastgit.xyz/ventanamicro/opensbi.git opensbi
git clone --branch dev-upstream --recurse-submodules --depth=1  https://hub.fastgit.xyz/ventanamicro/edk2.git tianocore/edk2
git clone --branch dev-upstream --recurse-submodules --depth=1  https://hub.fastgit.xyz/ventanamicro/edk2-platforms.git  tianocore/edk2-platforms
git clone --branch dev-upstream  https://hub.fastgit.xyz/ventanamicro/linux.git linux

编译构建

QEMU

cd $WORK_DIR/qemu
./configure --target-list=riscv64-softmmu
make -j $(nproc)

OPENSBI

此处我们使用以riscv64-unknown-elf-为前缀的版本，则表示该版本GCC工具链会使用newlib作为C运行库。原文使用riscv64-linux-gnu-，表示GCC工具链会使用Linux的Glibc作为C运行库。但是本人未编译成功。故后面编译工具均使用riscv64-unknown-elf-，与原文不同。

cd $WORK_DIR/opensbi
make ARCH=riscv CROSS_COMPILE=riscv64-unknown-elf- make PLATFORM=generic

EDK2 固件

此处原文里设置了一些环境变量在开头我们设置了，请不要重新设置，尤其不能export WORKSPACE=pwd，因为与源码脚本的WORKSPACE冲突。

cd $WORK_DIR/tianocore
source edk2/edksetup.sh
make -C edk2/BaseTools clean
make -C edk2/BaseTools
make -C edk2/BaseTools/Source/C
source edk2/edksetup.sh BaseTools
# 原文使用 -buildtarget RELEASE。但是提示 Not supported target RELEASE
build -a RISCV64 -b DEBUG -D FW_BASE_ADDRESS=0x80200000 -D EDK2_PAYLOAD_OFFSET -p Platform/Qemu/RiscvVirt/RiscvVirt.dsc -t GCC5

ERROR

StoreCurrentConfiguration:7: no such file or directory: /home/user/riscv64-acpi/tianocore/Conf/BuildEnv.sh

不要设置export WORKSPACE=pwd！！！如果所有方法都不可行，直接把路径写死export CONF_PATH=$WORK_DIR/tianocore/edk2/Conf
uuid/uuid.h: No such file or directory
```
sudo apt install uuid-dev
```

Not supported target RELEASE

# 将build命令改为如下，使用DEBUG版本。
build -a RISCV64 -b DEBUG -D FW_BASE_ADDRESS=0x80200000 -D EDK2_PAYLOAD_OFFSET -p Platform/Qemu/RiscvVirt/RiscvVirt.dsc -t GCC5

Linux

cd $WORK_DIR/linux
make ARCH=riscv CROSS_COMPILE=riscv64-unknown-elf- defconfig
make ARCH=riscv CROSS_COMPILE=riscv64-unknown-elf- -j $(nproc)

Rootfs

您可以使用您选择的任何 rootfs。此示例使用 buildroot。

此步耗时较久，与网络环境有关，如果网络不好可能按小时算。容易中断，需要重新下载。

cd $WORK_DIR/
git clone https://hub.fastgit.xyz/buildroot/buildroot.git
cd $WORK_DIR/buildroot
make qemu_riscv64_virt_defconfig
make rootfs-cpio

创建 EFI 分区并复制文件

fallocate -l 512M efi.img
sgdisk -n 1:34: -t 1:EF00 $WORK_DIR/efi.img
sudo losetup -fP $WORK_DIR/efi.img
loopdev=`losetup -j $WORK_DIR/efi.img | awk -F: '{print $1}'`
efi_part="$loopdev"p1
sudo mkfs.msdos $efi_part
mkdir -p /tmp/mnt
sudo mount $efi_part /tmp/mnt/
sudo cp $WORK_DIR/linux/arch/riscv/boot/Image /tmp/mnt/
sudo umount /tmp/mnt
sudo losetup -D $loopdev

运行

使用 virtio-blk 磁盘

原文参数-drive file=$WORK_DIR/buildroot/output/images/rootfs.ext2,format=raw,id=hd0需要更改如下。因为在编译 Rootfs 时的命令是make rootfs-cpio所以生成的是rootfs.cpio。无法找到rootfs.ext2

$WORK_DIR/qemu/build/qemu-system-riscv64 -nographic \
-machine virt,aclint=on,aia=aplic-imsic,acpi=on -cpu rv64,sscofpmf=true -smp 8  -m 2G  \
-bios $WORK_DIR/opensbi/build/platform/generic/firmware/fw_jump.elf \
-kernel $WORK_DIR/tianocore/Build/RiscvVirt/DEBUG_GCC5/FV/RISCVVIRT.fd  \
-drive file=$WORK_DIR/buildroot/output/images/rootfs.cpio,format=raw,id=hd0 \
-device virtio-blk-device,drive=hd0 \
-drive file=$WORK_DIR/efi.img,format=raw,id=hd1 \
-device virtio-blk-device,drive=hd1 \
-device virtio-net-device,netdev=usernet \
-netdev user,id=usernet,hostfwd=tcp::9990-:22

ERROR

无法找到rootfs.ext2

# 因为在编译 Rootfs 时的命令是 make rootfs-cpio 所以生成的是 rootfs.cpio
# 原文参数
-drive file=$WORK_DIR/buildroot/output/images/rootfs.ext2,format=raw,id=hd0 \
# 修改为
-drive file=$WORK_DIR/buildroot/output/images/rootfs.cpio,format=raw,id=hd0 \

无法找到RISCVVIRT.fd

# 因为编译 EDK2 固件时，参数是-b DEBUG 版本，原文是 RELEASE 版本，这两个版本路径不一样，所以找不到
# 原文参数
-kernel $WORK_DIR/tianocore/Build/RiscvVirt/RELEASE_GCC5/FV/RISCVVIRT.fd  \
# 修改为
-kernel $WORK_DIR/tianocore/Build/RiscvVirt/DEBUG_GCC5/FV/RISCVVIRT.fd  \

At EFI Shell:

Shell> fs0:\Image root=/dev/vdb console=ttyS0 rootwait earlycon

Responsive Image

使用 virtio-scsi 磁盘

$WORK_DIR/qemu/build/qemu-system-riscv64 -nographic \
-machine virt,aclint=on,aia=aplic-imsic,acpi=on -cpu rv64,ssofpmf=true -smp 8  -m 2G \
-bios $WORK_DIR/opensbi/build/platform/generic/firmware/fw_jump.elf \
-kernel $WORK_DIR/tianocore/Build/RiscvVirt/DEBUG_GCC5/FV/RISCVVIRT.fd  \
-device virtio-scsi-pci,id=scsi0,num_queues=4 \
-device scsi-hd,drive=drive0,bus=scsi0.0,channel=0,scsi-id=0,lun=0 \
-drive file=$WORK_DIR/buildroot/output/images/rootfs.cpio,format=raw,if=none,id=drive0 \
-device virtio-scsi-pci,id=scsi1,num_queues=4 \
-device scsi-hd,drive=drive1,bus=scsi0.0,channel=0,scsi-id=1,lun=0 \
-drive file=$WORK_DIR/efi.img,format=raw,if=none,id=drive1 \
-device virtio-net-device,netdev=usernet \
-netdev user,id=usernet,hostfwd=tcp::9990-:22

At EFI Shell:

Shell> fs0:\Image root=/dev/sda console=ttyS0 rootwait earlycon

在 QEMU 上运行 64 位和 32 位 RISC-V-Linux

Wed, 28 Jul 2021 13:47:56 +0000

制作交叉工具链 riscv-gnu-toolchain

下载源码

这个仓库是我遇到的最难下载的一个仓库了，公司网慢和虚拟机性能差都脱不了干系。估计下载了五小时都不止，刚开始还指望一个命令所有子模块都下载完的，结果愣是等了半天中断了。试了两次后放弃了。如果各位看官能一次完成，那您是福大。

国内的码云平台有个Gitee 极速下载项目，上面有 GitHub 的一些常用开源项目的镜像，可供加速下载。


# riscv-gnu-toolchain
https://gitee.com/mirrors/riscv-gnu-toolchain.git

下载时问题出现了，如果下载子模块仍然会卡住，如果不加--recursive就只能下载主体内容，子模块都没有。（以下内容为第一安装时的方法，后续又找到了git clone 快速下载子模块的方法）

开始下载时不加--recursive参数，只下载riscv-gnu-toolchain的主体内容，然后进入到riscv-gnu-toolchain文件夹下，手动下载子模块的内容。

当下完riscv-binutils继续下载riscv-gdb时发现这两个项目是同一个项目，只是不同的分支。但是码云上并没有区分，但是我也没找到在码云上的对应分支。只能用油猴脚本了。

如果你有油猴插件可以去greasyfork搜索安装GitHub 镜像访问，加速下载这个脚本，刷新 GitHub 仓库界面就会多出几个镜像地址，一般下载都会快好几倍。如果不用油猴插件的可以用我复制好的链接。

Responsive Image

# riscv-binutils
git clone https://gitee.com/mirrors/riscv-binutils-gdb.git
# riscv-gcc
git clone https://gitee.com/mirrors/riscv-gcc.git
# riscv-dejagnu
git clone https://gitee.com/mirrors/riscv-dejagnu.git
# riscv-glibc
git clone https://gitee.com/mirrors/riscv-glibc.git
# riscv-newlib
git clone https://gitee.com/mirrors/riscv-newlib.git
# riscv-gdb
git clone --depth=1 https://hub.fastgit.org/riscv/riscv-binutils-gdb.git

编译 riscv-gnu-toolchain

提前安装如下软件：

sudo apt-get install autoconf automake autotools-dev curl python3 libmpc-dev libmpfr-dev libgmp-dev gawk build-essential bison flex texinfo gperf libtool patchutils bc zlib1g-dev libexpat-dev

不听老人言，吃亏在眼前呀，本以为这是可选项，很多库都安装了，就没有操作这一步，结果就是编译半天结果还错了。如果报make 错误 127，那就老老实实把前置的这些库都装上。

建立riscv-gnu-toolchain安装目录/opt/riscv64。

./configure --prefix=/opt/riscv64 
sudo make linux -j8

导出安装路径

export PATH="$PATH:/opt/riscv64/bin"

出现一下信息表示安装成功。

Using built-in specs.
COLLECT_GCC=riscv64-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/opt/riscv64/libexec/gcc/riscv64-unknown-linux-gnu/10.2.0/lto-wrapper
Target: riscv64-unknown-linux-gnu
Configured with: /home/dominic/riscv64-linux/riscv-gnu-toolchain/riscv-gcc/configure --target=riscv64-unknown-linux-gnu --prefix=/opt/riscv64 --with-sysroot=/opt/riscv64/sysroot --with-system-zlib --enable-shared --enable-tls --enable-languages=c,c++,fortran --disable-libmudflap --disable-libssp --disable-libquadmath --disable-libsanitizer --disable-nls --disable-bootstrap --src=.././riscv-gcc --disable-multilib --with-abi=lp64d --with-arch=rv64imafdc --with-tune=rocket 'CFLAGS_FOR_TARGET=-O2   -mcmodel=medlow' 'CXXFLAGS_FOR_TARGET=-O2   -mcmodel=medlow'
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.2.0 (GCC)

制作内核

下载 Linux 内核

makefile

RISC-V on 夜云泊

SCP-firmware 源码分析-module 间 api 调用分析

SCP-firmware 源码分析 - 源码编译以及模块初始化流程

编译源码

下载配置工具链

编译源码

初始化流程分析

fwk_module_init 初始时，module_config_table 是在什么时候被初始化的？

如何确定各个模块在初始化过程中的执行顺序？

BusyBox 构建并启动 RISC-V Linux 内核

根文件系统

文件系统与根文件系统

基于内存的文件系统

根文件系统中各种配置文件的作用以及配置文件的格式介绍

/etc/inittab

/etc/fstab

/etc/init.d/rcS

/etc/profile

Busybox 简介以及如何制作 Busybox 文件系统

准备 QEMU

准备 OpenSBI

准备 Linux 内核

准备 Busybox

uCore-实验第 0 章 - 实验环境搭建

uCore-实验第 1 章 - 应用程序与基本执行环境

了解系统调用

makr run 之后发生了什么？

了解链接脚本

kernel.ld 中的 BASE_ADDRESS = 0x80200000 指定了内核的加载地址，这个地址哪来的？

终端是如何控制颜色的？

应用程序输出字符会调用 SBI 服务，SBI 中发生了什么？

内核中的 SBI 调用

ecall 服务调用流程

程序的内存布局与编译流程

程序的内存布局

uCore 的编译系统

附录

参考资料

uCore 实验第 5 章 - 进程及进程管理

进程初始化分析

wait 系统调用的功能

附录

uCore 实验第 4 章 - 地址空间

如何确定分页方案 - satp

SV39 多级页表机制

页表项描述

虚拟地址转换物理地址过程

如何建立页表

问答作业

请列举 SV39 页表页表项的组成，结合课堂内容，描述其中的标志位有何作用／潜在作用？

缺页相关问题

请问哪些异常可能是缺页导致的？

发生缺页时，描述相关的重要寄存器的值（lab2 中描述过的可以简单点）。

以下行为的好处？

请问处理 10G 连续的内存页面，需要操作的页表实际大致占用多少内存 (给出数量级即可)？

请简单思考如何才能在现有框架基础上实现 Lazy 策略，缺页时又如何处理？描述合理即可，不需要考虑实现。

此时页面失效如何表现在页表项 (PTE) 上？

双页表与单页表

单页表情况下，如何更换页表？

单页表情况下，如何控制用户态无法访问内核页面？（tips:看看第一题最后一问）

单页表有何优势？（回答合理即可）

双页表实现下，何时需要更换页表？假设你写一个单页表操作系统，你会选择何时更换页表（回答合理即可）？

附录

uCore 实验第 3 章 - 多道程序与分时多任务

LAB1

问答作业

问题一

问题二

L79: 刚进入 userret 时，a0、a1 分别代表了什么值。

L87-L88: sfence 指令有何作用？为什么要执行该指令，当前章节中，删掉该指令会导致错误吗？

L96-L125: 为何注释中说要除去 a0？哪一个地址代表 a0？现在 a0 的值存在何处？

userret：中发生状态切换在哪一条指令？为何执行之后会进入用户态？

L29：执行之后，a0 和 sscratch 中各是什么值，为什么？

L32-L61: 从 trapframe 第几项开始保存？为什么？是否从该项开始保存了所有的值，如果不是，为什么？

进入 S 态是哪一条指令发生的？

L75-L76: ld t0, 16(a0) 执行之后，t0中的值是什么，解释该值的由来？

uCore 实验第 2 章 - 批处理系统

QEMU启动RISC-V架构OpenEuler并配置OSC环境

安装QEMU

安装基础编译工具

kernel.ld 中的 `BASE_ADDRESS = 0x80200000` 指定了内核的加载地址，这个地址哪来的？

L79: 刚进入 `userret` 时，`a0`、`a1` 分别代表了什么值。

L87-L88: `sfence` 指令有何作用？为什么要执行该指令，当前章节中，删掉该指令会导致错误吗？

L96-L125: 为何注释中说要除去 `a0`？哪一个地址代表 `a0`？现在 `a0` 的值存在何处？

`userret`：中发生状态切换在哪一条指令？为何执行之后会进入用户态？

L75-L76: `ld t0, 16(a0)` 执行之后，`t0`中的值是什么，解释该值的由来？

Machine ISA Register `misa`

Machine Vendor ID Register `mvendorid`