RISC-V FreeRTOS启动过程分析（基于qemu+gdb调试）

目录

启动代码分析

RISC-V系统定时器初始化

任务创建以及栈帧初始化

启动第一个任务

使用GDB跟踪任务启动过程

---

        最近在学RISC-V架构，有幸找到了一个非常好的课程《循序渐进，学习开发一个RISC-V上的操作系统》，学完后受益匪浅，但是课程上开发的操作系统毕竟只是教学用，想对比学习一下实际商用的RTOS的实现。FreeRTOS以前也用过，是一个非常流行的开源RTOS，所以选择了qume+FreeRTOS分析学习相关代码。本文先分析RISC-V + qume + FreeRTOS的启动流程。

环境搭建可以参考

基于RISC-V的QEMU + FreeRTOS开发环境构建_qemu riscv_吹角连营G的博客-CSDN博客q

启动代码分析

启动文件入口FreeRTOS\Demo\RISC-V-Qemu-virt_GCC\start.S

        启动代码很简单，本人加了中文注释，上面的代码中51-61行，将data段从ROM加载到RAM中_data位置，打开编译生成的RTOSDemo.map文件，可以看到_data的地址为0x80080000（实际就是链接脚本指定的RAM的起始地址）， _data_lma地址为0x8000b338。

以上_data和_data_lma都是链接脚本里定义的，链接脚本如下：

FreeRTOS\Demo\RISC-V-Qemu-virt_GCC\fake_rom.lds

        这里和Linux有点不一样，Linux会把代码段数据段等...，整个内核都加载到内存中（一般为DDR）。RTOS一般用在单片机上，单片机一般没有DDR，程序直接片内Flash和片内SRAM运行。代码段、只读数据段不用从Flash加载到RAM，直接在片内Flash上（对应着上面的rom）取址执行，只把可读写数据段加载到内存，所以上面的代码只加载的.date(读写数据段)，没有加载代码段和.rodata(只读数据段)。

        对于_data和_data_lma的值，我们可以使用命令riscv64-unknown-elf-objdump -S -d build/RTOSDemo.axf > RTOSDemo.dsi，将编译后的RTOSDemo.axf 反汇编到RTOSDemo.dsi。使用gdb单步调试，对照反汇编文件，停在start.s 55行处，打印a0和a1寄存器的值也是8000b338和80080000。

        加载完date后清BSS，之后跳转到main函数了（实在有点快了，连异常入口都没有配置）

FreeRTOS\FreeRTOS\Demo\RISC-V-Qemu-virt_GCC\main.c

main函数中，先配置异常入口寄存器mtvec，mainVECTOR_MODE_DIRECT=0没有启用向量中断。所有异常和中断的入口地址都为freertos_risc_v_trap_handler。

关于RISC-V mtvec寄存器，功能类似armv8的VBAR_Elx寄存器，多了MODE向量中断配置：

接下来的main_blinky()函数，创建两个任务，之后调用vTaskStartScheduler()，系统就进入了Task的世界，vTaskStartScheduler函数不会退出。

vTaskStartScheduler中创建了idleTask（最低优先级的任务，没有其它活干时，总的有一个任务在运行，就轮到idleTask了，可以在其中做省电或者睡眠等处理），之后调用xTimerCreateTimerTask创建了软件定时器任务。函数最后调用xPortStartScheduler（和架构相关的调度器启动代码）。

xPortStartScheduler函数在FreeRTOS\Source\portable\GCC\RISC-V\port.c文件中

xPortStartScheduler中通过vPortSetupTimerInterrupt启动了系统定时器，之后配置mie（Machine Interrupt Enable）寄存器，最后xPortStartFirstTask启动了第一个任务，之后就进入Task世界了。

RISC-V系统定时器初始化

RISC-V系统定时器简单介绍下：

定时器初始化代码如下：

FreeRTOS\Source\portable\GCC\RISC-V\port.c

上面代码中加了详细注释，这里就不在啰嗦了。

任务创建以及栈帧初始化

        之前代码创建任务函数没有展开，直接跳过了。现在启动第一个任务需要涉及到创建任务的代码，这里对创建任务过程简单分析一下：

        创建任务时，创建一个任务控制块pxNewTCB（tskTaskControlBlock类型），任务控制块的第一个成员变量pxTopOfStack，保存着该任务的栈顶指针。创建任务过程中调用，pxPortInitialiseStack为任务初始化了任务栈。

pxPortInitialiseStack是一个汇编函数

FreeRTOS\Source\portable\GCC\RISC-V\portASM.S

        函数第一个参数pxTopOfStack是task栈顶指针对应a0寄存器，第二个参数pxCode为Task的入口函数对应a1寄存器，第三个参数pvParameters为pxCode入口函数的参数。该函数注释写的很明白，pxPortInitialiseStack就是为任务创建栈帧，并且返回新的栈顶指针，而且压栈顺序注释上也列出来了：先入mstatus -> xCriticalNesting -> x31 -> x30 ->x29 .... -> [chip specific registers go here] -> pxCode，其中[chip specific registers go here]，Qume没有specific registers需要保存，portasmADDITIONAL_CONTEXT_SIZE=0，代码中chip_specific_stack_frame跳过了。

        这里有特别说明一下，pxCode最后入栈也就是放在栈顶（sp偏移0位置），pvParameters放在x11和x9之前，直白一点就是应该放x10的位置，对照RISC-V寄存器表，x10就是a0，a0-a7根据RISC-V的ABI规范是用来传递参数的，a0是函数第一个参数，同时也做函数返回值。pvParameters是任务入口函数的参数，所以放在a0应该放的位置；pxCode实际上也是对应的放在了x1也就是ra寄存器的位置。这里没有保存x2、x3、x4，x2是sp放在TCB（任务控制块）的pxTopOfStack中（任务栈顶指针）；x3是gp指针在start.S中第一个初始化了，代码中不再修改，不保存；x4 tp线程指针，在Linux这种支持进程和线程的系统中才用到（可以搜索该项目的反汇编文件，没有使用x4或者tp，我们有需要可以自定义其它用途），所以也不保存。至于mstatus的值有详细注释，可以对照寄存器文档分析，这里略过。

启动第一个任务

        现在回到xPortStartFirstTask，该函数也在文件FreeRTOS\Source\portable\GCC\RISC-V\portASM.S中，而且就在pxPortInitialiseStack的下面，其实就这两个就是一对，一个先压栈，为任务准备栈帧；另一个出栈，使用栈帧为任务准备运行环境，并且最终启动任务（跳转到任务入口函数中执行）。

xPortStartFirstTask中首先从TCB中获取任务栈顶指针到sp，sp偏移0的位置保存着任务的入口函数，将任务入口函数恢复到x1（ra）；pvParameters恢复到了x10（a0）中，上面已经详细解释了。最后调用ret指令，cpu使用ra恢复到pc也就跳转到了任务入口函数中执行。

        到这里，cpu进入了Task世界，整个启动过程就结束了。

使用GDB跟踪任务启动过程

        启动gdb调试，加上3个断点xTaskCreate、pxPortInitialiseStack、xPortStartFirstTask。

        在断点xTaskCreate、pxPortInitialiseStack处打印处，a0、a1寄存器对比反汇编代码（或者对比map文件也一样）可以看到，和main_blinky()函数中创建任务时传递的参数是一致的，处理main_blinky中用户创建的task，系统还会自动创建IdleTask和TimerTask（config了软件定时器功能）。

        创建TimerTask的代码如下，入口函数prvTimerTask并且设置了最高优先级（毕竟是软件定时器可以看着rtos的软中断）。

       继续运行到xPortStartFirstTask时可以看到第一个启动的任务是TimerTask，将入口函数prvTimerTask写入到了ra寄存器，继续单步，等函数最后执行ret后就跳入到了prvTimerTask中，就切换到Task世界了，start.S 47行初始化的stack也就用不到了。

可以看到FreeRTOS一直运行在M模式，不像Linux有区分用户态和内核态。针对自己的SoC我们可以自己修改代码，将用户任务切换到U或者S模式，rtos自动创建的任务以及异常或者中断处理放在M模式中。