// 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 的模块需要做的事情就是：

1. 在模块的头文件中定义 API 的 ID，它有一定的格式，具体可以参考 MSCP 文档doc/framework.md的APIs章节。

   enum mod_modulename_api {
       MOD_MODULENAME_API_A,
       MOD_MODULENAME_API_B,
   };
   

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

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

3. 在模块原文件中提供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;
   }
   

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

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

5. 实现需要提供的 API 函数。

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

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

下载配置工具链

访问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文档。

初始化流程分析

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文件，这个文件中会包含所有模块的索引，如下：

目前为止的学习过程中，所有的程序都是运行在 Machine 模式下，但是在哪决定程序运行在什么模式下的呢？

在学习抢占式多任务时，我们有了创建任务的概念，在汇编代码中有这么一段，使用到了mstatus寄存器：

 # Notice: default mstatus is 0
 # Set mstatus.MPP to 3, so we still run in Machine mode after MRET.
 # Set mstatus.MPIE to 1, so MRET will enable the interrupt.
 li t0, 3 << 11 | 1 << 7
 csrr a1, mstatus     # a1 = mstatus
 or t0, t0, a1          # t0 = t0 | a1
 csrw mstatus, t0     # mstatus = t0

 j start_kernel  # hart 0 jump to c

mret返回后，是根据寄存器mstatus的MPP来决定接来来是处于什么模式，我们在上面将MPP配置为3， MPP的功能是 记录 Machine 模式下，前一个，特权级。这里解实现了在mret之后将模式设置为 Machine 模式（3）。

因为mstatus上电后默认为全 0，所以如果不对其设置，那么在mret之后，就是运行在用户态（0）。

如果想让程序跑在用户态，只要不对齐设置，保持默认即可：

 # Notice: default mstatus is 0
 # Set mstatus.MPP to 3, so we still run in Machine mode after MRET.
 # Set mstatus.MPIE to 1, so MRET will enable the interrupt.
 li t0, 1 << 7
 csrr a1, mstatus     # a1 = mstatus
 or t0, t0, a1          # t0 = t0 | a1
 csrw mstatus, t0     # mstatus = t0

 j start_kernel  # hart 0 jump to c

为什么需要系统调用？因为在用户态一些资源（寄存器）的访问是受限的，所以需要封装一些函数，这些函数里会进行模式切换，然后访问需要的资源。

那么如何进行模式的切换呢？这就需要ecall指令。它本质上是触发了异常，就会进入到 Machine 模式处理异常，在 Machine 模式下就相当于在内核态了，就没有访问资源的限制了。

系统模式的切换

ECALL指令实际就是主动触发异常，根据ECALL的权限级别产生不同的异常码，如下图：

从 User 模式调用ECALL异常码等于 8，从 Supervisor 模式调用异常码等于 9，从 Machine 模式调用异常码等于 11。

异常产生时epc寄存器的值存放的是ECALL指令本身的地址。

如果想触发完异常接着往下执行，需要在异常处理逻辑里把 epc 寄存器值改为下一条指令地址，否则会进入死循环。

系统调用的执行流程

系统调用的传参

系统调用作为操作系统的对外接口，由操作系统的实现负责定义。参考 Linux 的系统调用，RVOS 定义系统调用的传参规则如下：

• 系统调用号放在a7中
• 系统调用参数使用a0-a5
• 返回值使用a0

系统调用的封装

任务简介

多任务与上下文

任务就是一个指令执行流。

如果有多个 HART，那就可以同时执行多个指令执行流。

协作式多任务

协作式环境下，下一个任务被调度的前提是当前任务主动放弃处理器。

抢占式多任务

抢占式环境下，操作系统完全决定任务调度方案，操作系统可以剥夺当前任务对处理器的使用，将处理器提供给其它任务。

协作式多任务

上下文切换

切换过程需要完成：

• 保存上文（保存上一个任务的寄存器信息）
• 恢复下文（恢复下一个任务的寄存器信息）

CPU 中有 32 个寄存器，保存各种状态，在切换过程中我们主要关注两个寄存器：ra(x1) 存放返回地址，mscratch 一个特权寄存器，指向当前处理的任务。

切换过程

初始化寄存器，根据调用约定，ra都初始化为任务的第一条指令地址。mscratch开始指向 Task A。

Task A 稳定执行，当他想要放弃 CPU 时，就会执行 call swithc_to指令。执行call的过程中，就会把当前指令的下一条指令的地址放到 CPU 的ra寄存器。

接下里跳转到swithc_to函数执行，该函数是切换上下文的核心函数。首先保存上文，将 CPU 中的寄存器信息全部保存：

切换mscratch指针到下一个任务 Task B：

恢复下文：

当swithc_to函数执行到return时，接下来执行的指令就是 CPU 中ra保存的那条指令，也就是地址为j指令，这就是 Task B 的第一条指令，这样就完成了任务的切换。

源码分析

切换核心函数 switch_to

switch_to:
 csrrw t6, mscratch, t6 # swap t6 and mscratch
 beqz t6, 1f   # Notice: previous task may be NULL
 reg_save t6   # save context of prev task
                        # 把CPU的信息保存到内存

 # Save the actual t6 register, which we swapped into
 # mscratch
 mv t5, t6  # t5 points to the context of current task
 csrr t6, mscratch # read t6 back from mscratch
 sw t6, 120(t5) # save t6 with t5 as base

1:
 # switch mscratch to point to the context of the next task
 csrw mscratch, a0

 # Restore all GP registers
 # Use t6 to point to the context of the new task
 mv t6, a0
 reg_restore t6      # 把内存里的信息恢复到CPU

 # Do actual context switching.
 ret

创建和初始化第一号任务

使用结构体context保存上下文中寄存器的信息：

struct context {
 /* ignore x0 */
 reg_t ra;
 reg_t sp;
 reg_t gp;
 reg_t tp;
 reg_t t0;
 reg_t t1;
 reg_t t2;
 reg_t s0;
 reg_t s1;
 reg_t a0;
 reg_t a1;
 reg_t a2;
 reg_t a3;
 reg_t a4;
 reg_t a5;
 reg_t a6;
 reg_t a7;
 reg_t s2;
 reg_t s3;
 reg_t s4;
 reg_t s5;
 reg_t s6;
 reg_t s7;
 reg_t s8;
 reg_t s9;
 reg_t s10;
 reg_t s11;
 reg_t t3;
 reg_t t4;
 reg_t t5;
 reg_t t6;
};

#define STACK_SIZE 1024
uint8_t task_stack[STACK_SIZE];
struct context ctx_task;

写一个任务函数，功能就是每隔1000 滴答打印一句话。

void user_task0(void)
{
 uart_puts("Task 0: Created!\n");
 while (1) {
  uart_puts("Task 0: Running...\n");
  task_delay(1000);
 }
}

初始化任务，需要初始化栈，并把任务的首地址保存到context的ra寄存器。

void sched_init()
{
 w_mscratch(0);

 ctx_task.sp = (reg_t) &task_stack[STACK_SIZE - 1];
 ctx_task.ra = (reg_t) user_task0;
}

切换到第一个用户任务

switch_to函数的参数就是上下文，当执行到ret时也就切换到了user_task0。

void schedule()
{
 struct context *next = &ctx_task;
 switch_to(next);
}

以上是单任务的情况，如果是多任务时，就用数组保存多个context，最大支持 10 个任务。

#define MAX_TASKS 10
#define STACK_SIZE 1024
uint8_t task_stack[MAX_TASKS][STACK_SIZE];
struct context ctx_tasks[MAX_TASKS];

使用简单的求模取余的方式确定下一个任务是哪一个：

/*
 * _top is used to mark the max available position of ctx_tasks
 * _current is used to point to the context of current task
 */
static int _top = 0;
static int _current = -1;

/*
 * implment a simple cycle FIFO schedular
 */
void schedule()
{
 if (_top <= 0) {
  panic("Num of task should be greater than zero!");
  return;
 }

 _current = (_current + 1) % _top;
 struct context *next = &(ctx_tasks[_current]);
 switch_to(next);
}

因为多个任务协作，需要一个函数来表示主动放弃 CPU：

/*
 * DESCRIPTION
 *  task_yield()  causes the calling task to relinquish the CPU and a new 
 *  task gets to run.
 */
void task_yield()
{
 schedule();
}

调用关系

抢占式多任务

抢占式多任务：抢占式环境下，操作系统完全决定任务调度方案，操作系统可以剥夺当前任务对处理器的使用，将处理器提供给其他任务。

寄存器

对 MSIP 写入 1 时触发 软中断，写入 0 时表示对中断进行应答，也就是处理完了软中断。

任务同步与锁

并发与同步

并发：多个控制流同时执行

• 多处理器多任务
• 单处理器多任务
• 单处理器任务 + 中断

同步：为了保证在并发执行的环境中各个控制流可以有效执行而采用的一种编程技术

临界区、锁与死锁

临界区：在并发的程序执行环境中，所谓临界区指的是一个会访问共享资源的指令片段，而且当这样的多个指令片段同时访问某个共享资源时可能会引发问题。

在并发环境下为了有效控制临界区的执行（同步），我们要做的是当有一个控制流进入临界区时，其他相关控制流必须等待。

锁：一种常见的用来实现同步的技术

• 不可睡眠锁
• 可睡眠锁

当发生中断时，右边的任务获取 CPU 资源，开始执行，但是获取锁时发现当前已经处于锁定状态，所以就处于等待状态。

当下一个中断发生，左侧任务回去 CPU 后会继续执行，实际上左侧任务也不必等待，他可以一直执行，因为右侧任务一直无法获取锁。

当然，右侧任务也可以一直触发中断，让左侧任务让出 CPU。也就是左侧任务逻辑上可以一直运行，但是实际还是会被打断。

当左侧任务执行完释放锁，右侧任务就可以获取锁，并正常执行下去。

死锁：当控制流执行路径中会涉及多个锁，并且这些控制流执行路径获取的顺序不同时就可能发送死锁。

解决死锁：

• 调整获取锁的顺序，比如保持一致
• 尽可能防止任务在持有一把锁同时申请其他锁

自旋锁

不能从 C 语言的层面去理解锁，应该要从指令级别去理解。上面的这种上锁方式是有问题的。

如果两个控制流同时加锁，就可能同时获取了锁，因为在汇编指令级别，每条指令执行也是需要时间的：

AMOSWAP

loop:
    lw a4, -20(s0)  # 参数1
    li a5, 1        # 参数 2
    amoswap.w.aq a5, a5, (a4)   # 将a5与a4指向的内存的值进行交换
                                # 将 1 与 a4 交换，表示如果原来上锁（1）那就什么都没做
                                # 如果原来没上锁（0）那就立即上锁 
    mv a3, a5
    bnez a3,loop

![](https://picbed-1311007548.cos.ap-shanghai.myqcloud.com/markdown_picbed/img//2022/08/28/21-38-57-b7cece2166dba14bd128970cefdd2702-20220828213857-b116cd.png)

ENTRY

功能：用于设置入口点，即程序中执行的第一条指令 symbol 参数是一个符号的名称

OUTPUT_ARCH

功能：指定输出文件所适用的计算机体系架构

为什么用 riscv64-unknown-elf-gcc，但是编译出来的文件是 32 位程序？ riscv64 是 host 是 64 位系统，编译 target 是由 gcc 的参数决定

MEMORY

功能：用于描述目标机器上内存区域的位置，大小和相关

MEMORY
{
    /* 内存类型为ROM，起始地址0，长度256K */
    rom(rx):ORIGIN = 0, LENGTH = 256K
    /* 内存类型为RAM，起始地址0x40000000，长度4M */
    ram(!rx):org = 0x40000000, l = 4M
}

TODO：括号里的 rx 含义是？

SECTION

功能：告诉链接器如何将 input sections 映射到 output sections，以及如何将 output sections 放置到内存中。

SECTION
{
    .=0x0000;
    .text:{*(.text)}
    .=0x8000000;
    .data:{*(.data)}
    .bss:{*(.bss)}
}>ram

PROVIDE

功能：

• 可以在 Linker Script 中定义符号（Symbols）
• 每个符号包括一个名字（name) 和一个对应的地址值（address）
• 在代码中可以访问这些符号，等同于访问一个地址。

 .bss :{
  PROVIDE(_bss_start = .);    /* 当前地址赋值给符号_bss_start */
  *(.sbss .sbss.*)
  *(.bss .bss.*)
  *(COMMON)
  PROVIDE(_bss_end = .);
 } >ram
    PROVIDE(_memory_start = ORIGIN(ram));
 PROVIDE(_memory_end = ORIGIN(ram) + LENGTH(ram));

 PROVIDE(_heap_start = _bss_end); /* 堆空间就是接在了bss段之后，所以堆开始地址就是bss结束地址 */ 
 PROVIDE(_heap_size = _memory_end - _heap_start); /* 计算堆大小 */ 

.global表示全局变量，.word表示定义变量，下面的代码就是定义一些全局变量，方便在 C 代码中使用。

/* mem.S */ 
.section .rodata
.global HEAP_START
HEAP_START: .word _heap_start

.global HEAP_SIZE
HEAP_SIZE: .word _heap_size

.global TEXT_START
TEXT_START: .word _text_start

.global TEXT_END
TEXT_END: .word _text_end

.global DATA_START
DATA_START: .word _data_start

.global DATA_END
DATA_END: .word _data_end

.global RODATA_START
RODATA_START: .word _rodata_start

.global RODATA_END
RODATA_END: .word _rodata_end

.global BSS_START
BSS_START: .word _bss_start

.global BSS_END
BSS_END: .word _bss_end

/*
 * Following global vars are defined in mem.S
 */
extern uint32_t TEXT_START;
extern uint32_t TEXT_END;
extern uint32_t DATA_START;
extern uint32_t DATA_END;
extern uint32_t RODATA_START;
extern uint32_t RODATA_END;
extern uint32_t BSS_START;
extern uint32_t BSS_END;
extern uint32_t HEAP_START;
extern uint32_t HEAP_SIZE;

#define PAGE_SIZE 4096
static uint32_t _num_pages = _num_pages = (HEAP_SIZE / PAGE_SIZE) - 8;

实现 Page 级别的内存分配与释放

日常使用的操作系统，都是以字节为单位分配空间，但是为了教学方便，RVOS 是以 Page 为单位分配内存。

数据结构设计

数组方式管理

将内存模拟为一个连续的数组，数组的前部预留 8 个 Page 来管理其余的内存。目前考虑管理的状态有：

• 这 Page 是否被使用了
• 这个 Page 是不是最后一块分配的内存，方便我们释放内存时找到最后一块分配的内存

我们可以使用一个 8 bit 的flag来记录这些信息，flag bit[0]表示是否已使用，flag bit[1]表示是否是最后一个分配的页面。

/*
 * Page Descriptor 
 * flags:
 * - bit 0: flag if this page is taken(allocated)
 * - bit 1: flag if this page is the last page of the memory block allocated
 */
struct Page {
 uint8_t flags;
};

也就是每一个 Page 都由一个 8 bit 的结构体struct Page管理，我们总共分配了 8 个 Page 用来管理，一个 Page 占 4K，那么我们可以一个管理$8 \times 4096 = 32768$个 Page。那就刚好可以管理$32768 \times 4096 = 134217728 \text{bit}$内存=128M。

Page 分配与释放接口设计

/*
 * 分配连续n个可用物理页
 * - npages: 需要分配的页的个数
 */
void *page_alloc(int npages)
{
 /* Note we are searching the page descriptor bitmaps. */
 int found = 0;
 struct Page *page_i = (struct Page *)HEAP_START;
 for (int i = 0; i < (_num_pages - npages); i++) {
  if (_is_free(page_i)) {
   found = 1;
   /* 
    * 找到第一个可用Page，继续判断是否有N个连续可用page
    */
   struct Page *page_j = page_i;
   for (int j = i; j < (i + npages); j++) {
    if (!_is_free(page_j)) {
     found = 0;
     break;
    }
    page_j++;
   }
   /*
    * 找到了连续的N个可用page，将N个page设置为已分配状态
    */
   if (found) {
    struct Page *page_k = page_i;
    for (int k = i; k < (i + npages); k++) {
     _set_flag(page_k, PAGE_TAKEN);
     page_k++;
    }
    page_k--;
    _set_flag(page_k, PAGE_LAST);
                // 返回可用page首地址
    return (void *)(_alloc_start + i * PAGE_SIZE);
   }
  }
  page_i++;
 }
 return NULL;
}

/*
 * 释放已分配的物理页
 * - p: 待释放的首地址
 */
void page_free(void *p)
{
 /*
  * 判断非法输入，p不能为空或者超出最大可分配大小
  */
 if (!p || (uint32_t)p >= _alloc_end) {
  return;
 }
 /* 计算出这个首地址p所在的page的描述符，也就是找到第几个描述符在管理这块内存 */
 struct Page *page = (struct Page *)HEAP_START;
 page += ((uint32_t)p - _alloc_start)/ PAGE_SIZE;
 /* 循环清空标识 */
 while (!_is_free(page)) {
  if (_is_last(page)) {
   _clear(page);
   break;
  } else {
   _clear(page);
   page++;;
  }
 }
}

控制流（Control Flow）和 Trap

• 控制流（Control Flow） 从给处理器加电开始，直到你断电为止，程序计数器假设一个值的序列 $$a_0,a_1,\dotsb,a_{n-1}$$ 每个$a_k$都是指令的地址，每次从$a_{k}$到$a_{k+1}$的过渡称为控制转移，而这样的控制转移序列叫做处理器的控制流。
• 异常控制流（Exceptional Control Flow, ECF） 系统也必须能够对系统状态的变化做出反应，这些系统状态不是被内部程序变量捕获的，而且也不一定要和程序的执行相关。比如，一个硬件定时器定期产生信号，这个事件必须得到处理。包到达网络适配器后，必须存放在内存中。程序向磁盘请求数据，然后休眠，直到被通知说数据已就绪。现代系统通过使控制流发生突变来对这些情况做出反应。我们把这些突变称为异常控制流。
  • exception
  • interrupt

RISC-V 把 ECF 统称为 Trap。

RISC-V Trap 处理中涉及的寄存器

mtvec（Machine Trap-Vector Base-Address）

WARL: Write Any Values, Read Legal Values

• BASE：trap 入口函数的基地址，必须保证四字节对齐；

• MODE：进一步用于控制入口函数的地址配置方式：

  • Direct，所有异常和中断发生后，PC都跳转到BASE指定的地址处；

    

    通常中断处理函数内部会有switch case条件语句，通过不同的中断采用不同的处理方式。

    reg_t trap_handler(reg_t epc, reg_t cause)
    {
        reg_t return_pc = epc;
        reg_t cause_code = cause & 0xfff;
    
        if (cause & 0x80000000) {
            /* Asynchronous trap - interrupt */
            switch (cause_code) {
            case 3:
                uart_puts("software interruption!\n");
                break;
            case 7:
                uart_puts("timer interruption!\n");
                break;
            case 11:
                uart_puts("external interruption!\n");
                break;
            default:
                uart_puts("unknown async exception!\n");
                break;
            }
        } else {
            /* Synchronous trap - exception */
            printf("Sync exceptions!, code = %d\n", cause_code);
            panic("OOPS! What can I do!");
            //return_pc += 4;
        }
    
        return return_pc;
    }
    

  • Vectored，异常的处理方式同上，但是中断的入口地址以数组方式排列；

    trap_vector:
        # save context(registers).
        csrrw t6, mscratch, t6 # swap t6 and mscratch
        reg_save t6
    
        # Save the actual t6 register, which we swapped into
        # mscratch
        mv t5, t6  # t5 points to the context of current task
        csrr t6, mscratch # read t6 back from mscratch
        sw t6, 120(t5) # save t6 with t5 as base
    
        # Restore the context pointer into mscratch
        csrw mscratch, t5
    
        # call the C trap handler in trap.c
        csrr a0, mepc
        csrr a1, mcause
        call trap_handler
    
        # trap_handler will return the return address via a0.
        csrw mepc, a0
    
        # restore context(registers).
        csrr t6, mscratch
        reg_restore t6
    
        # return to whatever we were doing before trap.
        mret
    

    MODE可取值如下：

    

采用Vectored方式效率更高。

mepc（Machine Exception Program Counter）

当trap发生时，pc会被替换为 mtvec设定的地址，同时hart 会设置mepc为当前指令或者下一条指令的地址（处理异常时，mepc 为当前指令的地址，处理中断时，mepc 为下一条指令的地址）。

当我们需要退出trap 时可以调用特殊的 mret 指令，该指令会将mepc中的值恢复到pc中（实现返回的效果）；

在处理 trap 的程序中我们可以修改 mepc 的值达到改变mret 返回地址的目的。

mcause（Machine Cause）

当 trap 发生时，hart 会设置该寄存器通知我们 trap 发生的原因。

最高位 Interrupt 为 1 时标识了当前 trap 为interrupt，否则是exception。

剩余的 Exception Code 用于标识具体的interrupt或者exception 的种类。

mtval（Machine Trap Value）

当 trap 发生时，除了通过mcause 可以获取exception的种类 code 值外，hart 还提供了 mtval 来提供exception 的其他信息来辅助我们执行更进一步的操作。

具体的辅助信息由特定的硬件实现定义，RISC-V 规范没有定义具体的值。但规范定义了一些行为，譬如访问地址出错时的地址信息、或者执行非法指令时的指令本身等。

mstatus（Machine Status）

寄存器各个位可以大致分为以下三类，其中x可以为U,S,M。表示用户模式以及两种特权模式。

• xIE（x=M/S/U）: 分别用于打开（1）或者关闭（0）M/S/U 模式下的全局中断。当 trap 发生时，hart会自动将 xIE 设置为 0。

• xPIE（x=M/S/U）:当 trap 发生时用于保存 trap 发生之前的 xIE 值。

• xPP（x=M/S）:当 trap 发生时用于保存 trap 发生之前的权限级别值。注意没有 UPP。因为异常只会从低权限向高权限跳转，通常低权限如user模式，会被置于上方，高权限如内核一般都会画在下方，这也解释了异常，中断处理为什么叫trap，因为是向下陷入的过程。

• 其他标志位涉及内存访问权限、虚拟内存控制等，暂不考虑。

Trap 处理流程

主要为 Exception，下一章详解 Interrupt。

初始化

将trap的基地址写入寄存器，

Top Half

1. 把 mstatus 的 MIE 值复制到 MPIE 中，清除 mstatus中的 MIE 标志位，效果是中断被禁止。
2. 设置mepc，同时PC被设置为 mtvec。（需要注意的是，对于exception， mepc指向导致异常的指令；对于 interrupt，它指向被中断的指令的下一条指令的位置。）
3. 根据 trap 的种类设置 mcause，并根据需要为mtval设置附加信息。
4. 将 trap 发生之前的权限模式保存在 mstatus 的 MPP 域中，再把hart 权限模式更改为 M（也就是说无论在任何 Level 下触发trap，hart 首先切换到 Machine 模式）。

Bottom Half

1. 保存（save）当前控制流的上下文信息（利用 mscratch）；
2. 调用 C 语言的 trap handler;
3. 从 trap handler 函数返回，mepc的值有可能需要调整；
4. 恢复（restore）上下文的信息；
5. 执行MRET指令返回到 trap之前的状态。

trap_vector:
 # save context(registers).
 csrrw t6, mscratch, t6 # swap t6 and mscratch
 reg_save t6

 # Save the actual t6 register, which we swapped into
 # mscratch
 mv t5, t6  # t5 points to the context of current task
 csrr t6, mscratch # read t6 back from mscratch
 sw t6, 120(t5) # save t6 with t5 as base

 # Restore the context pointer into mscratch
 csrw mscratch, t5

 # call the C trap handler in trap.c
 csrr a0, mepc
 csrr a1, mcause
 call trap_handler

 # trap_handler will return the return address via a0.
 csrw mepc, a0

 # restore context(registers).
 csrr t6, mscratch
 reg_restore t6

 # return to whatever we were doing before trap.
 mret

退出 trap：编程调用 MRET 指令

针对不同权限级别下如何退出 trap 有各自的返回指令xRET（x = M/S/U）。以在 M 模式下执行mret 指令为例，会执行如下操作：

• 当前 Hart 的权限级别 = mstatus.MPP；mstatus.MPP = U（如果 hart 不支持 U 则为 M）
• mstatus.MIE = mstatus.MPIE; mstatus.MPIE = 1
• pc = mepc

中断

中断分类

• 本地（Local）中断

  • 软中断software interrupt
  • 定时器中断 timer interrupt

• 全局（Global）中断

  • 外部中断 externel interrupt

RISC-V 中断编程中涉及的寄存器

mie(Machine Interrupt Enable)

打开（1）或者关闭（0）M/S/U 模式下对应的 External/Timer/Software 中断。

mip(Machine Interrupt Pending)

获取当前 M/S/U 模式下对应的 External/Timer/Software 中断是否发生。

中断处理流程

中断处理

1. 把 mstatus 的 MIE 值复制到 MPIE 中，清除 mstatus 中的 MIE 标志位，效果是中断被禁止。
2. 当前的 PC 的下一条指令地址被复制到 mepc 中，同时 PC 被设置为mtvec。注意如果我们设置 mtvec.MODE = vetcored，PC =mtvec.BASE + 4 × exception-code。
3. 根据 interrupt 的种类设置 mcause，并根据需要为 mtval 设置附加信息。
4. 将 trap 发生之前的权限模式保存在 mstatus 的 MPP 域中，再把hart 权限模式更改为 M。

退出中断

以在 M 模式下执行 mret 指令为例，会执行如下操作：

• 当前 Hart 的权限级别 = mstatus.MPP; mstatus.MPP= U（如果 hart 不支持 U 则为 M）
• mstatus.MIE = mstatus.MPIE; mstatus.MPIE = 1
• pc = mepc

PLIC（Platform-Level Interrupt Controller）

PLIC 简介

HART 只能处理一个中断，PLIC 相当于一个控制中心，它通过中断类型，优先级等等来选出一个需要处理的中断。协调多个中断，服务一个 HART。

enum {
    UART0_IRQ = 10, //Interrupt Source ID
    RTC_IRQ = 11,
    VIRTIO_IRQ = 1, /* 1 to 8 */
    VIRTIO_COUNT = 8, 
    PCIE_IRQ = 0x20, /* 32 to 35 */
    VIRTIO_NDEV = 0x35 /* Arbitrary maximum number of interrupts */
};

• Interrupt Source ID 范围：1 ~ 53（0x35）
• 0 预留不用

PLIC本身也是一个外设，RISC-V 规范规定，PLIC 的寄存器编址采用内存映射（memory map）方式。每个寄存器的宽度为 32-bit。

具体寄存器编址采用 base + offset 的格式，且 base 由各个特定platform 自己定义。针对 QEMU-virt，其 PLIC 的设计参考了FU540-C000，base 为 0x0c000000。

static const MemMapEntry virt_memmap[] = {
    [VIRT_DEBUG] =       {        0x0,         0x100 },
    [VIRT_MROM] =        {     0x1000,        0xf000 },
    [VIRT_TEST] =        {   0x100000,        0x1000 },
    [VIRT_RTC] =         {   0x101000,        0x1000 },
    [VIRT_CLINT] =       {  0x2000000,       0x10000 },
    [VIRT_ACLINT_SSWI] = {  0x2F00000,        0x4000 },
    [VIRT_PCIE_PIO] =    {  0x3000000,       0x10000 },
    [VIRT_PLIC] =        {  0xc000000, VIRT_PLIC_SIZE(VIRT_CPUS_MAX * 2) },
    [VIRT_UART0] =       { 0x10000000,         0x100 },
    [VIRT_VIRTIO] =      { 0x10001000,        0x1000 },
    [VIRT_FW_CFG] =      { 0x10100000,          0x18 },
    [VIRT_FLASH] =       { 0x20000000,     0x4000000 },
    [VIRT_PCIE_ECAM] =   { 0x30000000,    0x10000000 },
    [VIRT_PCIE_MMIO] =   { 0x40000000,    0x40000000 },
    [VIRT_DRAM] =        { 0x80000000,           0x0 },
};

PLIC 编程接口 - 寄存器

Priority

功能：设置某一路中断源的优先级 内存映射地址：BASE + (interrupt-id) * 4

• 每个 PLIC 中断源对应一个寄存器，用于配置该中断源的优先级。
• QEMU-virt 支持 7 个优先级。0 表示对该中断源禁用中断。其余优先级，1 最低，7 最高。
• 如果两个中断源优先级相同，则根据中断源的 ID 值进一步区分优先级，ID 值越小的优先级越高。

Pending

功能：用于指示某一路中断源是否发生 内存映射地址：BASE + 0x1000 + ((interrupt-id) / 32) * 4

• 每个 PLIC 包含 2 个 32 位的 Pending 寄存器，因为总共有 54 个中断源，每一个 bit 对应一个中断源，如果为 1 表示该中断源上发生了中断（进入Pending 状态），有待 hart 处理，否则表示该中断源上当前无中断发生。
• Pending 寄存器中断的 Pending 状态可以通过claim 方式清除。
• 第一个 Pending 寄存器的第 0 位对应不存在的 0 号中断源，其值永远为 0。

Enable

功能：针对某个 hart 开启或者关闭某一路中断源 内存映射地址：BASE + 0x2000 + (hart) * 0x80

• 每个 Hart 有 2 个 Enable 寄存器（Enable1 和 Enable2）用于针对该Hart 启动或者关闭某路中断源。
• 每个中断源对应 Enable 寄存器的一个 bit，其中Enable1 负责控制 1 ~ 31 号中断源；Enable2 负责控制 32 ~ 53 号中断源。将对应的 bit 位设置为 1 表示使能该中断源，否则表示关闭该中断源。

Threshold

功能：针对某个 hart 设置中断源优先级的阈值 内存映射地址：BASE + 0x200000 + (hart) * 0x1000

• 每个 Hart 有 1 个 Threshold 寄存器用于设置中断优先级的阈值。
• 所有小于或者等于（<=）该阈值的中断源即使发生了也会被 PLIC 丢弃。特别地，当阈值为 0 时允许所有中断源上发生的中断；当阈值为 7 时丢弃所有中断源上发生的中断。

Claim/Complete

功能：如下 内存映射地址：BASE + 0x200004 + (hart) * 0x1000

• Claim 和 Complete 是同一个寄存器，每个 Hart 一个。
• 对该寄存器执行读操作称之为 Claim，即获取当前发生的最高优先级的中断源ID。Claim 成功后会清除对应的 Pending 位。
• 对该寄存器执行写操作称之为 Complete。所谓 Complete指的是通知PLIC 对该路中断的处理已经结束。

void external_interrupt_handler()
{
 int irq = plic_claim(); //

 if (irq == UART0_IRQ){
        uart_isr();
 } else if (irq) {
  printf("unexpected interrupt irq = %d\n", irq);
 }
 
 if (irq) {
  plic_complete(irq); //
 }
}

CLINT （Core Local INTerruptor）

定时器中断，属于本地中断的一种，由芯片内部CLINT设备产生的中断。

• RISC-V 规范规定，CLINT 的寄存器编址采用内存映射（memory map）方式。
• 具体寄存器编址采用base + offset的格式，且 base 由各个特定 platform 自己定义。针对 QEMU-virt，其 CLINT 的设计参考了 SFIVE，base 为 0x2000000。

CLINT 编程接口 - 寄存器 (Timer 部分)

mtime

功能：real-time 计数器（counter） 内存映射地址：BASE + 0xbff8

• 由晶振产生，系统全局唯一，在 RV32 和 RV64 上都是 64-bit。系统必须保证该计数器的值始终按照一个固定的频率递增。
• 上电复位时，硬件负责将 mtime 的值恢复为 0。

mtimecmp

功能：定时器比较寄存器 内存映射地址：BASE + 0x4000 + (hart) * 8)

• 每个 hart 一个 mtimecmp 寄存器，64-bit。

• 上电复位时，系统不负责设置 mt`imecmp 的初值。

• 当mtime >= mtimecmp 时，CLINT 会产生一个 timer 中断。如果要使能该中断需要保证全局中断打开并且mie.MTIE 标志位置 1。

• 当 timer 中断发生时，hart 会设置 mip.MTIP，程序可以在 mtimecmp 中写入新的值清除mip.MTIP。

时钟节拍 tick

• 操作系统中最小的时间单位；
• Tick 的单位（周期）由硬件定时器的周期决定 （通常为 1 ~ 100ms）；
• Tick 周期越小，也就是1s内产生的中断越多，系统的精度越高，但开销越大。

操作系统（英语：Operating System，缩写：OS）是一组系统软件程序，狭义上就是内核如 Linux，广义上就是内核加一组软件组成的发行包，如 Ubuntu，Debian：

• 主管并控制计算机操作、运用和运行硬件、软件资源

• 提供公共服务来组织用户交互。

硬件的基本概念

• Hart
• Platform 不能说是个板子，应该理解为芯片。早期的板子就是一块芯片加上各种外设，但是随着技术发展，板子越来越小，外设却并没有变少，是因为外设都被集成到了芯片中。当所有外设都被集成，那么芯片就是 platform。
• SoC(System on Chip) 片上系统

QEMU 模拟 virt 这个平台，这个平台有八个 Hart。

地址映射

为了方便访问外设，现在主流的 platform 会对外设的内存地址做一个映射。映射到 platform 的真实物理地址。对真实物理地址进行操作时，就是对外设的地址进行操作。

物理地址从最低位到最高位都被分配给了各种外设。

引导过程介绍

通电后，会先到箭头所指的地址，这个地址就是对应的 ROM 外设首地址。ROM 相当于一个小硬盘，断电后不会丢失数据。这里面固化了一些指令。

主要就是跳转指令，运行到 kernel 段继续执行。

八核同时会执行这个过程。

以上是硬件的部分过程，软件该如何写？

为了简化学习流程和降低调试难度，目前只支持单核，其余七个核处于空转状态。

如何判断当前 Hart 是不是第一个？

这些寄存器必须使用以下的指令读写：

以上指令就是将寄存器值进行一次交换，只不过这个过程是原子性的，不能被打断。

CSRRW经常会用在伪指令CSRW中，完整指令中，第一步向x0写入数据，就是空操作，第二步将rs写入csr。这个伪指令就是完成了一个写入csr的操作。

mhartid就是machine hart id。

学习以上几个指令，就可以完成判断 hart 是否为第一个的工作了，

csrr t0, mhartid    #读寄存器值
mv tp, t0           #
bnez t0, park       # 跳转指令，不等于 0 就跳转到 park 标签

wfi
休眠指令

如何初始化栈空间

如何跳转到 C 语言环境

# start.S
#include "platform.h"

    # size of each hart's stack is 1024 bytes
    .equ    STACK_SIZE, 1024

    .global    _start

    .text
_start:
    # park harts with id != 0
    csrr    t0, mhartid     # read current hart id
    mv      tp, t0          # keep CPU's hartid in its tp for later usage.
    bnez    t0, park        # if we're not on the hart 0
                            # we park the hart
    # Setup stacks, the stack grows from bottom to top, so we put the
    # stack pointer to the very end of the stack range.
    slli    t0, t0, 10      # shift left the hart id by 1024

    ###### 初始化栈空间 ######
    # set the initial stack pointer to the end of the first stack space
    la      sp, stacks + STACK_SIZE    
    # move the current hart stack pointer to its place in the stack space
    add     sp, sp, t0       
    ###### 初始化栈空间  ######
    
    ###### 跳转到C语言环境 ######
    j       start_kernel     # hart 0 jump to c, start_kernel is the entry point of the kernel
    ###### 跳转到C语言环境 ######

park:
    wfi
    j    park

stacks:
    # allocate space for all the harts stacks
    .skip    STACK_SIZE * MAXNUM_CPU 
    .end                # End of file

// kernel.c
void start_kernel(void)
{
  while (1) {}; // stop here!
}

通过 UART 打印信息

连接方式

真实的硬件开发是有一个快开发板，但是这个课程里使用的是 QEMU 来模拟开发板的硬件环境。如果要在程序里打印一段信息，正常的情况是在开发板上连接显示器，但是这里是通过将信息用串口传到主机上，然后用主机的屏幕显示信息。

串口线里是有两根线，负责收信息和发信息。

UART 特点

• 并行就是需要多根线，比如有两根线，那么就可以一次发送两位。但是串行节省材料。
• 数据通信就会涉及同步的问题，同步的话需要一根时钟线来协商好发送时间和接收时间。而 UART 使用异步，发送的数据不仅仅是真实的数据，还会带有一些标识信息。这些标识可以判断出是收还是发。

物理接口

UART 通讯协议

图示中横轴可以表示时间，纵轴表示高低电平。

在需要发送数据时，会进行“下拉”1bit，1bit 持续的时间就是波特率分之一秒。

数据在发送过程中可能会受到干扰，会产生畸变，所以需要检验位来判断是否发生畸变。

初始化

在软件中，配置 UART 就是配置寄存器的信息。

在板子上有个元器件叫晶振（crystal），他会产生固定频率的时钟。一种是 1.8432MHZ，一种是 7.3728MHZ。想要获得指定的输出频率就需要对寄存器进行配置。查表可以得到配置信息。比如获得 38.4K 频率的输出，就要配置寄存器值为 3。

LCR 寄存器功能比较多，将第 7 位设置为 1 就是用来设置波特率。

图中DLL和DLM寄存器就是需要配置的寄存器。因为 UART 寄存器都是 8 位的，将值0x0003高位0x00存在DLM中，将低位0x03存入DLL。

一条典型的 RISC-V 汇编语句由三个部分组成[label:][operation][comment]。 后缀.s和.S区别：后者纯汇编。

• label(标号)
• operation 可以有以下多种类型：
  • instruction (指令) ：直接对应二进制机器指令的宇符串
  • pseudo-instruction (伪指令) ：为了提高编写代码的效率，可以用一条伪指令指示汇编器产生多条实际的指令 (instructions)。
  • directive (指示/伪操作) ：通过类似指令的形式(以".“开头),通知汇编器如何控制代码的产生等，不对应具体的指令。
  • macro：采用.macro/.endm 自定义的宏 例子

.macro do_nothing  # directive
  nop    # pseudo-instruction
  nop    # pseudo-instruction
.endm      # directive

  .text    # directive
  .global _start  # directive
_start:     # Label
  li x6, 5  # pseudo-instruction
  li x7, 4  # pseudo-instruction
  add x5, x6, x7  # instruction
  do_nothing  # Calling macro
stop:  j stop    # statement in one line

  .end    # End of file

• comment（注释）以#开头到行尾

RISC-V 汇编指令总览

操作对象

• 寄存器
  • 32个通用寄存器,x0 ~ x31（注意：本章节课程仅涉及RV32I的通用寄存器组）；
  • 在 RISC-V 中，Hart 在执行算术逻辑运算时所操作的数据必须直接来自寄存器。
• 内存
  • Hart可以执行在寄存器和内存之间的数据读写操作；
  • 读写操作使用字节 (Byte) 为基本单位进行寻址；
  • RV32可以访问最多2^32个字节的内存空间。

编码格式

指令长度：32bit，本文讨论的都是 RV32 指令集

指令对齐：指令加载到内存是以 32bit 对齐

funct3、funct7和opcode一起决定指令类型，funct3表示占 3bit，funct7占 7bit。

opcode映射关系：

• [1:0] 永远为 11
• [4:2] 为下图横轴
• [6:5] 为下图纵轴，三部分决定指令的类型。

以BEQ指令为例opcode=1100011。[4:2]=000，[6:5]=11查表可得BEQ指令类型为BRANCH。

小端序

• 主机字节序 (HBO-Host Byte Order)
• 一个多字节整数在计算机内存中存储的字节顺序称主机字节序 (HBO- Host Byte Order，或者叫本地字节序)
• 不同类型 CPU 的 HBO 不同，这与 CPU 的设计有关。分为大端序 (Big-Endian) 和小端序 (Little-Endian)

指令分类

rd（register destination）目标寄存器，rs（register source）源寄存器，大小都是 5bit，因为可以表示2^5=32寄存器。

指令详解

算术运算指令

ADD

算数指令只包含加减，不包含乘除，乘除运算有专门的扩展。

数据传送顺序是由后向前，和正常的编码习惯类似。

SUB Substract

练习

现知道某条 RISC-V 的机器指令在内存中的值为b3 05 95 00,从左往右为从低地址到高地址，单位为字节，请将其翻译为对应的汇编指令。

• 确定字节序 在 RISC-V 中存放是小端序，根据题意真正指令应该是00 95 05 b3
• 转换二进制 机器码是二进制，所以需要将上述指令值转换为二进制，可得0000000 01001 01010 000 01011 0110011
• 查阅手册 查阅The RISC-V Instruction Set Manual Volume I: Unprivileged ISA找到RV32/64G Instruction Set Listings指令表格，低 7 位是opcode，查表可得0110011对应操作码有多个SLLI SRAI SUB等等，此时再看最高位00000000,可以确定是ADD指令
• 将分割的二进制转成十进制 0000000 9 10 000 11 010011->ADD x11 x10 x9

ADDI ADD Immediate

LUI Load Upper Immediate

LI

AUIPC

经常用于构造一个相对地址。

LA

基于算术运算指令实现的其他伪指令

x0寄存器具有特殊含义，往里写数据没有意义 NOP指令主要为了占位，空转

逻辑运算指令

NOT

10101010
11111111(-1)
--------  XOR
01010101

移位运算指令

算数移位

只有右移，没有左移。左移会把最高位覆盖。

10001000 >> 2
= 11100001

内存读写指令

加载，内存读，将数据从内存读入寄存器

Store，内存写，将数据从寄存器写出到内存

为何对 word 的 加载 不区分无符号和有符号方式 (RV32)？RV32 下寄存器是 4 字节，加载 word 也是 4 字节，自然不需要扩展。

为何 store 不区分有符号还是无符号？因为从目的地址只有 1 字节，不管是写 1 字节，2 字节，还是 4 字节，都只用到最低的 1 字节。不需要考虑符号

立即数分两个地方存，为了解码效率

条件分支指令

指令格式中的立即数 (imm) 存放有些奇怪，第 [1-4] 位和第 [11] 位放在一起，第 [5-10] 位和第 [12] 位放在一起。这是为了迎合硬件处理效率，编程时不需要考虑立即数存储方式。

无条件跳转指令

int a = 1;
int b = 1;

void sum()
{
  a = a+b;
  return;   // jalr x0 0(x5)  当前指令的下一条指令存到x0中，并跳转到（0 + x5)，也就是sum的下一条指令
}

void _start()
{
  sum(); // jal x5 sum  把sum的下一条指令存到x5，然后跳转到sum
  ...
}

如何解决长距离跳转？使用 AUIPC 来构建一个大数，配合 JALR 使用。如 auipc x6,imm-20 jalr x1,x6,imm-12

RISC-V 指令寻址模式总结

汇编函数调用约定

函数调用过程概述

栈（stack）数据结构，在函数调用过程中会用来保存变量，函数地址等等。

栈帧里保存的变量是自动变量，会被内存自动释放。

为何要有调用者与被调用者保存的概念

函数调用过程中就会有参数和返回值的传递，自己写的函数可能由别人来调用，如果没有约定好某个参数存放位置，就不能够顺利执行函数。

因为寄存器需要经常在编程中使用，所以 ABI 名就是寄存器的别名。

这些寄存器其实都可以设置成被调用者保存，也就是在被调用函数中保存一遍为啥还要分这么多 答：因为保存一遍效率低

尾调用实例

# Calling Convention
# Demo to create a leaf routine
#
# void _start()
# {
#     // calling leaf routine
#     square(3);
# }
#
# int square(int num)
# {
#     return num * num;
# }

  .text        # Define beginning of text section
  .global  _start    # Define entry _start

_start:
  la sp, stack_end  # prepare stack for calling functions

  li a0, 3      # pass 3 to square
  call square     # call square

  # the time return here, a0 should stores the result
stop:
  j stop        # Infinite loop to stop execution

# int square(int num)
square:
  # prologue
  addi sp, sp, -8     # reserve space for local variables
  sw s0, 0(sp)     # save s0
  sw s1, 4(sp)      # save s1

  # `mul a0, a0, a0` should be fine,
  # programing as below just to demo we can contine use the stack
  mv s0, a0           # s0 = a0
  mul s1, s0, s0      # s1 = s0 * s0
  mv a0, s1        # a0 = s1

  # epilogue
  lw s0, 0(sp)      # restore s0
  lw s1, 4(sp)     # restore s1
  addi sp, sp, 8      # release space for local variables
  
  ret          # return from function

  # add nop here just for demo in gdb
  nop 

  # allocate stack space
stack_start:
  .rept 10     # reserve 10 words for stack
  .word 0     # fill with 0
  .endr        # end of repeat
stack_end: 

  .end      # End of file

非尾调用实例

# Calling Convention
# Demo how to write nested routines
#
# void _start()
# {
#     // calling nested routine
#     aa_bb(3, 4);
# }
#
# int aa_bb(int a, int b)
# {
#     return square(a) + square(b);
# }
#
# int square(int num)
# {
#     return num * num;
# }

  .text        # Define beginning of text section
  .global  _start    # Define entry _start

_start:
  la sp, stack_end  # prepare stack for calling functions

  # aa_bb(3, 4);
  li a0, 3      # load argument a
  li a1, 4      # load argument b
  call aa_bb       # call aa_bb

stop:
  j stop      # Infinite loop to stop execution

# int aa_bb(int a, int b)
# return a^2 + b^2
aa_bb:
  # prologue
  addi sp, sp, -16  # decrement stack pointer by 16 bytes
  sw s0, 0(sp)    # save s0
  sw s1, 4(sp)    # save s1
  sw s2, 8(sp)    # save s2
  sw ra, 12(sp)    # save ra
  
  # cp and store the input params
  mv s0, a0      # copy a to s0
  mv s1, a1      # copy b to s1

  # sum will be stored in s2 and is initialized as zero
  li s2, 0      # initialize s2 to zero

  mv a0, s0      # copy s0 to a0
  jal square      # call square
  add s2, s2, a0    # add a0 to s2
  
  mv a0, s1      # copy s1 to a0
  jal square      # call square
  add s2, s2, a0    # add a0 to s2
  
  mv a0, s2      # copy s2 to a0

  # epilogue
  lw s0, 0(sp)    # restore s0
  lw s1, 4(sp)    # restore s1    
  lw s2, 8(sp)    # restore s2
  lw ra, 12(sp)    # restore ra
  addi sp, sp, 16    # increment stack pointer by 16 bytes
  ret          # return from aa_bb

# int square(int num)
square:
  # prologue
  addi sp, sp, -8    # decrement stack pointer by 8 bytes
  sw s0, 0(sp)    # save s0
  sw s1, 4(sp)    # save s1

  # `mul a0, a0, a0` should be fine,
  # programing as below just to demo we can contine use the stack
  mv s0, a0      # copy a to s0
  mul s1, s0, s0    # s1 = a * a
  mv a0, s1      # copy s1 to a0

  # epilogue
  lw s0, 0(sp)    # restore s0      
  lw s1, 4(sp)    # restore s1
  addi sp, sp, 8    # increment stack pointer by 8 bytes
  
  ret          # return from square
  
  # add nop here just for demo in gdb
  nop            

  # allocate stack space
stack_start:
  .rept 10      # allocate 10 words of stack space
  .word 0        # initialize stack space to 0
  .endr        # end of stack allocation
stack_end:
  .end      # End of file

汇编与 C 混合编程

前提

遵守 ABI（Abstract Binary Interface）的规定

• 数据类型大小，布局，对齐
• 函数调用约定
• 系统调用约定 等等

RISC-V 函数调用约定规定

• 函数参数采用寄存器a0-a7
• 函数返回值采用寄存器a0,a1

汇编嵌入 C 语言

# ASM call C

  .text      # Define beginning of text section
  .global  _start    # Define entry _start
  .global  foo    # foo is a C function defined in test.c

_start:
  la sp, stack_end  # prepare stack for calling functions

  # RISC-V uses a0 ~ a7 to transfer parameters
  li a0, 1
  li a1, 2
  call foo    #调用了C语言函数
  # RISC-V uses a0 & a1 to transfer return value
  # check value of a0

stop:
  j stop      # Infinite loop to stop execution

  nop      # just for demo effect

stack_start:
  .rept 10
  .word 0
  .endr
stack_end:

  .end      # End of file

call foo就是在调用 C 语言函数，foo。 .global foo告诉编译器foo函数定义在外面。

C 语言嵌入汇编

下图中为简化写法

计算机硬件基础

两大硬件架构

• 冯诺依曼架构

  • 一根总线，开销小，控制逻辑实现简单

  • 执行效率低

• 哈佛架构

  • 与上一架构相反

程序的存储与执行

.c文件经过编译链接，生成.out文件。加载到内存中，到控制单元运行。进行取值，译码，执行。

晶振发出脉冲。

语言的设计与进化

本文主要涉及 VSCode 的相关配置，编译及调试工具需要提前安装好。

• 已经安装好riscv-toolchain，包括riscv64-unknown-elf-gcc，riscv64-unknown-elf-gdb
• 已经安装好qemu，包括riscv32-softmmu,riscv32-linux-user,riscv64-softmmu,riscv64-linux-user
• 已经安装好g++,gdb

调试流程简介

对于我这样的新手，要调试一个项目源码最怕的就是开始，也就是怎么能把项目跑起来。

我们以一个简单的test项目，看看在 VSCode 里怎么跑起来。

拿到源码后，将其以文件夹形式，加入到 VSCode 中，文件 - 打开文件夹 - 选择 test 项目文件夹。项目就会在 VSCode 中打开，但是此时我们还无法编译运行，我们需要在 VSCode 上 构建出一个 C 语言的编译与调试环境。

首先得安装一个插件C/C++，打开插件中心Ctrl+Shit+X，搜索，安装。

然后输入F5，会弹出对话框，选择C++(GDB)，继续选择g++。VSCode 会自动创建.vscode文件夹，已经两个文件launch.json和tasks.json。

launch.json用来配置调试环境，tasks.json主要用来配置编译环境，当然也可以配置其他任务。task.json里配置的每个任务其实就相当于多开一个控制台。

配置tasks.json

因为我们先要编译源码，生成.out或者.exe文件，才能调试，所以先进行编译任务配置。

自动生成的文件是个配置模板，我们可以根据自己的实际情况进行配置，也有一部分可以保持默认。

// tasks.json
{
    // https://code.visualstudio.com/docs/editor/tasks
    "version": "2.0.0",
    "tasks": [
        {
             // 任务的名字，注意是大小写区分的
             //会在launch中调用这个名字
            "label": "C/C++: g++ build active file", 
             // 任务执行的是shell
            "type": "shell", 
             // 命令是g++
            "command": "g++", 
             //g++ 后面带的参数
            "args": [
                "'-Wall'",
                "-g",           // 生成调试信息，否则无法进入断点
                "'-std=c++17'",     //使用c++17标准编译
                "'${file}'",        //当前文件名
                "-o",               //对象名，不进行编译优化
                "'${fileBasenameNoExtension}.exe'",  //当前文件名（去掉扩展名）
            ],
        }
    ]
}

如果项目是通过 Makefile 编译的，那就更加简单，只需要配置一个任务即可。

{
  "version": "2.0.0",
  "tasks": [
    {
       //任务的名字方便执行
      "label": "Make Project",
      "type": "shell",
      "command": "make",
      "args":[
          //8线程编译
          "-j8",
      ],
    },
  ]
}

运行该任务时就会执行make命令进行编译。

配置launch.json

// launch.json

{
    "version": "0.2.0",
    "configurations": [
        {
            //调试任务的名字
            "name": "g++ - Build and debug active file", 
            //在launch之前运行的任务名，这个名字一定要跟tasks.json中的任务名字大小写一致
            "preLaunchTask": "C/C++: g++ build active file",  
            "type": "cppdbg",
            "request": "launch",
            //需要运行的是当前打开文件的目录中，
            //名字和当前文件相同，但扩展名为exe的程序
            "program": "${fileDirname}/${fileBasenameNoExtension}.exe", 
            "args": [],
            // 选为true则会在打开控制台后停滞，暂时不执行程序
            "stopAtEntry": false,
            // 当前工作路径：当前文件所在的工作空间
            "cwd": "${workspaceFolder}",
            "environment": [],
            // 是否使用外部控制台
            "externalConsole": false,  
            "MIMode": "gdb",
            "setupCommands": [
                {
                    "description": "Enable pretty-printing for gdb",
                    "text": "-enable-pretty-printing",
                    "ignoreFailures": true
                }
            ]
        }]
}

运行

经过以上配置后，我们打开main.cpp文件，在cout处打一个断点，按F5，即可编译，运行，调试。一定要打开main.cpp文件，不能随便打开文件就开始哦。因为我们在配置时使用了一些预定义，比如${file}表示当前文件，所以只有打开需要调试的文件才能开始。

程序将会在cout语句停下来。

我们可以注意一下界面下方的控制台，可以更直观了解launch.jason和tasks.jason。

右边的框，就是我们在tasks.jason中配置的任务，左边的框就是我们在tasks.jason中command以及args的内容，他就是帮我们提前写好编译的选项。然后在 shell 中运行。

编译调试 RISC-V 程序

了解以上这些，就可以按需配置所需的环境了。我们还是从tasks.jason开始。因为开发用的电脑是x86的，所以先要编译出riscv的程序，再用模拟器模拟出rsicv的环境，然后在模拟的环境中运行程序，最后才能开始调试。

假设已经安装好开头所提到的工具。首先配置tasks.jason：

{
    "version": "2.0.0",
    "tasks": [
        {
            // 编译当前代码
            "type": "shell",
            "label": "C/C++(RISCV): Build active file",
            // 编译器的位置
            "command": "/opt/riscv/bin/riscv64-unknown-elf-g++",
            "args": [
                "-Wall", // 开启所有警告
                "-g", // 生成调试信息s
                "${file}",
                "-o",
                "${workspaceFolder}/debug/${fileBasenameNoExtension}" // 我选择将可执行文件放在debug目录下
            ],
            // 当前工作路径：执行当前命令时所在的路径
            "options": {
                "cwd": "${workspaceFolder}"
            },
            "problemMatcher": [
                "$gcc"
            ]
        },
        {
            // 启动qemu供调试器连接
            "type": "shell",
            "label": "Run Qemu Server(RISCV)",
            "dependsOn": "C/C++(RISCV): Build active file",
            "command": "qemu-system-riscv64",
            "args": [
                "-g",
                "65500", // gdb端口，自己定义
                "${workspaceFolder}/debug/${fileBasenameNoExtension}"
            ],
        },
        {
            // 有时候qemu有可能没法退出，故编写一个任务用于强行结束qemu进程
            "type": "shell",
            "label": "Kill Qemu Server(RISCV)",
            "command": "ps -C qemu-riscv64 --no-headers | cut -d \\  -f 1 | xargs kill -9",
        }
    ]
}

tasks.jason是可以配置多个任务的，第一个任务用来编译成riscv架构下的程序，第二个任务用来启动 qemu，让程序在 qemu 上运行起来。

第一个任务中，command就是配置编译器riscv64-unkonown-elf-gcc的属性，第二个任务中，command是配置 qemu 模拟器qemu-system-riscv32的属性。第三个任务中，用来配置结束 qemu 模拟器的命令。

接下来配置launch.jason：

{
    "version": "0.2.0",
    "configurations": [
        { 
            "name": "C/C++(RISCV) - Debug Active File",
            "type": "cppdbg",
            "request": "launch",
            "program": "${workspaceFolder}/debug/${fileBasenameNoExtension}",
            "args": [],
            "stopAtEntry": false,
            "cwd": "${workspaceFolder}",
            "environment": [],
            "externalConsole": false,
            "MIMode": "gdb",
            "setupCommands": [
                {
                    "description": "为 gdb 启用整齐打印",
                    "text": "-enable-pretty-printing",
                    "ignoreFailures": true
                }
            ],
            // RISC-V工具链中的gdb
            "miDebuggerPath": "/opt/riscv/bin/riscv64-unknown-elf-gdb", 
            // 这里需要与task.json中定义的端口一致
            "miDebuggerServerAddress": "localhost:65500" 
        }
    ]
}

我们在配置x86下的调试环境时，launch.jason中有个"preLaunchTask": "C/C++: g++ build active file"，属性，这个属性的目的是在启动调试之前，先执行任务名字为"C/C++: g++ build active file"任务，也是就编译的任务。

因为启动 qemu 会导致阻塞，所以这里没有加preLaunchTask，在启动调试之前，先把 qemu 运行起来。输入Ctrl+Shift+P，打开 VSCode 命令行。输入Run Task，

点击第一个，选择任务，我们可以看到出现的三个任务就是我们在tasks.jason中配置的三个任务。选择第一个 Build，编译出程序，再重复操作，选择第三个执行 QEMU 任务。

预定义变量

官网