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

RISC-V FreeRTOS启动过程分析(基于qemu+gdb调试)_第1张图片

        启动代码很简单,本人加了中文注释,上面的代码中51-61行,将data段从ROM加载到RAM中_data位置,打开编译生成的RTOSDemo.map文件,可以看到_data的地址值为0x80080000(实际就是链接脚本指定的RAM的起始地址), _data_lma地址值为0x8000b338(_data实际是一个变量,但是这里放一个变量是为了得到变量的地址,而不关心变量的值,程序中la a1 _data相当于a1 = &_data)。

RISC-V FreeRTOS启动过程分析(基于qemu+gdb调试)_第2张图片

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

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

RISC-V FreeRTOS启动过程分析(基于qemu+gdb调试)_第3张图片

RISC-V FreeRTOS启动过程分析(基于qemu+gdb调试)_第4张图片

        这里和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。

RISC-V FreeRTOS启动过程分析(基于qemu+gdb调试)_第5张图片

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

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

RISC-V FreeRTOS启动过程分析(基于qemu+gdb调试)_第6张图片

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

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

RISC-V FreeRTOS启动过程分析(基于qemu+gdb调试)_第7张图片

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

RISC-V FreeRTOS启动过程分析(基于qemu+gdb调试)_第8张图片

RISC-V FreeRTOS启动过程分析(基于qemu+gdb调试)_第9张图片

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

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

RISC-V FreeRTOS启动过程分析(基于qemu+gdb调试)_第10张图片

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

RISC-V系统定时器初始化

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

RISC-V FreeRTOS启动过程分析(基于qemu+gdb调试)_第11张图片

RISC-V FreeRTOS启动过程分析(基于qemu+gdb调试)_第12张图片

RISC-V FreeRTOS启动过程分析(基于qemu+gdb调试)_第13张图片

定时器初始化代码如下:

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

RISC-V FreeRTOS启动过程分析(基于qemu+gdb调试)_第14张图片

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

任务创建以及栈帧初始化

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

RISC-V FreeRTOS启动过程分析(基于qemu+gdb调试)_第15张图片

RISC-V FreeRTOS启动过程分析(基于qemu+gdb调试)_第16张图片

RISC-V FreeRTOS启动过程分析(基于qemu+gdb调试)_第17张图片

RISC-V FreeRTOS启动过程分析(基于qemu+gdb调试)_第18张图片

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

pxPortInitialiseStack是一个汇编函数

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

RISC-V FreeRTOS启动过程分析(基于qemu+gdb调试)_第19张图片RISC-V FreeRTOS启动过程分析(基于qemu+gdb调试)_第20张图片

        函数第一个参数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的值有详细注释,可以对照寄存器文档分析,这里略过。

RISC-V FreeRTOS启动过程分析(基于qemu+gdb调试)_第21张图片

启动第一个任务

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

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

RISC-V FreeRTOS启动过程分析(基于qemu+gdb调试)_第22张图片

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

使用GDB跟踪任务启动过程

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

RISC-V FreeRTOS启动过程分析(基于qemu+gdb调试)_第23张图片

RISC-V FreeRTOS启动过程分析(基于qemu+gdb调试)_第24张图片

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

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

RISC-V FreeRTOS启动过程分析(基于qemu+gdb调试)_第25张图片

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

RISC-V FreeRTOS启动过程分析(基于qemu+gdb调试)_第26张图片

RISC-V FreeRTOS启动过程分析(基于qemu+gdb调试)_第27张图片

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

你可能感兴趣的:(RISC-V,FreeRTOS,risc-v)