FreeRTOS 中 RISC-V-Qemu-virt_GCC 的 运行流程

已于 2022-07-08 18:32:14 修改
阅读量836 收藏
点赞数
分类专栏： riscv 文章标签： stm32
于 2021-09-16 19:51:45 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/u011011827/article/details/120336068
版权

该文章 中讲述了 FreeRTOS RISC-V-Qemu-virt_GCC 的 启动流程,本篇文章讲述一下 运行了流程

我将  RISC-V-Qemu-virt_GCC 做了一些改动
FreeRTOS/Demo/RISC-V-Qemu-virt_GCC/main_blinky.c 改为如下

static void prvQueueSendTask( void *pvParameters )
{

        for( ;; )
        {
                vSendString( "1111" );
       		 	vTaskDelay(1000);
        }
}

/*-----------------------------------------------------------*/

static void prvQueueReceiveTask( void *pvParameters )
{
        for( ;; )
        {
                vSendString( "2222" );
        		vTaskDelay(1000);
        }
}

/*-----------------------------------------------------------*/

int main_blinky( void )
{
    vSendString( "Hello FreeRTOS!" );

    /* Create the queue. */
    /* Start the two tasks as described in the comments at the top of this
       file. */
    xTaskCreate( prvQueueReceiveTask, "Rx", configMINIMAL_STACK_SIZE * 2U, NULL,
            mainQUEUE_RECEIVE_TASK_PRIORITY, NULL );
    xTaskCreate( prvQueueSendTask, "Tx", configMINIMAL_STACK_SIZE * 2U, NULL,
            mainQUEUE_SEND_TASK_PRIORITY, NULL );

   	vTaskStartScheduler();

    return 0;
}
如何从代码编译角度查看系统中有多少任务
1. 系统创建的任务
	grep portTASK_FUNCTION_PROTO * -nr
	// 该实例中 系统创建了 两个 prvTimerTask 和 prvIdleTask
	// prvTimerTask 在 freertos boot 时 被 用到 , 后来就没有进入该函数了,不知道该task是否被销毁
2. 用户 创建的任务
	grep -w "xTaskCreate(" * -nr
	// 该实例中 用户创建了 两个 prvQueueReceiveTask prvQueueSendTask
流程
我将按时间流走过的流程总结为如下
	1. boot
	2. fist task 			// prvTimerTask
	3. mtimer interrupt 	// freertos_risc_v_trap_handler xTaskIncrementTick  processed_source
	4. fist task & ecall    // prvTimerTask ecall freertos_risc_v_trap_handler vTaskSwitchContext processed_source
	5. second task & ecall  // prvQueueReceiveTask ecall freertos_risc_v_trap_handler vTaskSwitchContext processed_source
	6. third task & ecall   // prvQueueSendTask ecall freertos_risc_v_trap_handler vTaskSwitchContext processed_source
	7. fourth task & ecall  // prvIdleTask  ??? freertos_risc_v_trap_handler vTaskSwitchContext 
	8. third task ...

	当前配置里面 不会在 mtimer interrupt 中 调度, 只能用户任务主动调度
  • 1.boot
_start
	main
		main_blinky
			vTaskStartScheduler
				xPortStartScheduler
					xPortStartFirstTask
						...
						ret
  • 2.fist task
任务1:prvTimerTask // 该任务开始执行后, 会时不时的进入 machine timer 中断
	prvProcessTimerOrBlockTask
		刚进入就产生 mtimer 中断
  • 3.mtimer interrupt
freertos_risc_v_trap_handler // mtimer 中断导致进入
	保存任务1
	test_if_asynchronous
	handle_asynchronous
	test_if_mtimer
		xTaskIncrementTick
	processed_source
		mret
  • 4.fist task & ecall
任务1:prvTimerTask
	prvProcessTimerOrBlockTask
		.. 中间有很多 mtimer 中断
		portYIELD_WITHIN_API/ecall
		
freertos_risc_v_trap_handler // ecall 中断导致进入
	保存任务1
	test_if_asynchronous
	handle_synchronous
	test_if_environment_call
	vTaskSwitchContext
		taskSELECT_HIGHEST_PRIORITY_TASK
			// 这里切换 pxCurrentTCB 到 任务2
	processed_source
		mret
  • 5.second task & ecall
任务2:prvQueueReceiveTask
	vSendString("2222");
	vTaskDelay/portYIELD_WITHIN_API/ecall

freertos_risc_v_trap_handler // ecall 中断导致进入
	保存任务1
	test_if_asynchronous
	handle_synchronous
	test_if_environment_call
	vTaskSwitchContext
		taskSELECT_HIGHEST_PRIORITY_TASK
			// 这里切换 pxCurrentTCB 到 任务3
	processed_source
		mret
  • 6.third task & ecall
任务3:prvQueueSendTask
	vSendString("1111");
	vTaskDelay/portYIELD_WITHIN_API/ecall


freertos_risc_v_trap_handler // ecall 中断导致进入
	保存任务1
	test_if_asynchronous
	handle_synchronous
	test_if_environment_call
	vTaskSwitchContext
		taskSELECT_HIGHEST_PRIORITY_TASK
			// 这里切换 pxCurrentTCB 到 任务4
	processed_source
		mret
  • 7.fourth task & ecall
任务4:prvIdleTask
	// 进来了很多 mtimer 中断
	// 一次 taskYIELD/ecall


freertos_risc_v_trap_handler // ecall 中断导致进入
	保存任务1
	test_if_asynchronous
	handle_synchronous
	test_if_environment_call
	vTaskSwitchContext
		taskSELECT_HIGHEST_PRIORITY_TASK
			// 这里切换 pxCurrentTCB 到 任务3
	processed_source
		mret
  • 8.third task …
任务3:prvQueueSendTask
	vSendString("1111");
	vTaskDelay/portYIELD_WITHIN_API/ecall
	...
ecall 后的 freertos_risc_v_trap_handler
1. ecall // 此时的 寄存器状态为A(包括  ra  sp  gp  tp  t0  t1  t2  s0  s1  a0  a1  a2  a3  a4  a5  a6  a7  s2  s3  s4  s5  s6  s7  s8  s9  s10 s11 t3  t4  t5  t6  pc )
	
	此时硬件做动作
		mcause 被设置成 0xb
		mepc 被设置成 0x80001d28

2. freertos_risc_v_trap_handler // 此时寄存器状态为B // A和B  除了pc,其他都一样
freertos_risc_v_trap_handler 

	// 1. 保存 寄存器信息 到 sp
	addi sp, sp, -portCONTEXT_SIZE // sp = sp - 120 // 可以保存 30个 寄存器
	store_x x1, 1 * portWORD_SIZE( sp ) // 保存x1(第一个寄存器) 到 sp , sp = sp +4 // sw  ra,4(sp)
	store_x x5, 2 * portWORD_SIZE( sp ) // 保存x2(第二个寄存器)
	...
	store_x x31, 28 * portWORD_SIZE( sp ) // 保存x31(第28个寄存器)
	
	csrr t0, mstatus
	store_x t0, 29 * portWORD_SIZE( sp ) // 保存 mstatus(第29个寄存器)到sp
	
	portasmSAVE_ADDITIONAL_REGISTERS // 用户自定义的 保存寄存器 的 指令,一般为空
	
	// 2. 保存sp 到 当前的 TCB
	load_x  t0, pxCurrentTCB
	store_x  sp, 0( t0 ) 
		// 保存 sp 到 pxCurrentTCB的第一个成员 , 即
		// volatile StackType_t * pxTopOfStack							
		// 32bit x/30xw pxCurrentTCB->pxTopOfStack							
		// 64bit x/30xg pxCurrentTCB->pxTopOfStack
	// 3. 此时 保存完毕,开始处理异常

	// 4. 读 mcause mepc
	csrr a0, mcause
	csrr a1, mepc
	

	// 5. 判断 同步还是异步
	test_if_asynchronous:
	srli a2, a0, __riscv_xlen - 1 // 高 16 位存储到 a2
	beq a2, x0, handle_synchronous // 如果 a2 等0 ,跳转到 handle_synchronous  , 实际上ecall ,会走 handle_synchronous  
	
	// 6. 处理同步
	handle_synchronous:
	addi a1, a1, 4 // 处理返回地址 ,返回地址 = mepc +4
	store_x a1, 0( sp ) // 填充到 返回地址 到  sp 指向的内存
	
	// 7. 判断是不是 ecall
	test_if_environment_call:
	li t0, 11 // 将 11 放到 t0 // 11 表示 Environment call from M-mode
	bne a0, t0, is_exception // 如果 a0(即mcause)等于 t0(即11) , 那么就 不跳到 is_exception ,而是继续往下
	-------------------------------------------------------------------------------------------//此时切换了sp
	// 从 0x80082cf8 -> 0x80091da0
	// 为什么在此时才切换sp
	// 往前, 刚保存完 返回地址的recipe , 又往后 做了 三个汇编指令(该三条汇编指令用不到sp,也不会影响sp)
	// 往后, 要用sp 调用 C代码vTaskSwitchContext , vTaskSwitchContext 中会改动 sp
	// 所以 在此时 切换sp
	load_x sp, xISRStackTop // 设置 sp 为 xISRStackTop 
	-------------------------------------------------------------------------------------------
	

	// 8. 选择下一个 TCB , 将其 赋值给 pxCurrentTCB 
	jal vTaskSwitchContext
		taskSELECT_HIGHEST_PRIORITY_TASK/__clzSI2(UWtype x) 
			// __clzSI2 来自于crosstool-ng-crosstool-ng-1.24.0/.build/riscv64-unknown-elf/src/gcc/libgcc/libgcc2.c
			// 参数x 为 7
			count_leading_zeros (ret, x); // 这里切换了 pxCurrentTCB 
	
	// 9. load下个任务
	j processed_source
		// 获取(恢复) 下个任务 的 sp // 此时 恢复的 sp 中 保存的 是   寄存器状态 值
		load_x  t1, pxCurrentTCB // 保存 pxCurrentTCB  到 t1
		load_x  sp, 0( t1 ) 	//  从 TCB 中读取 sp
		
		// 获取(恢复) 下个任务 的 mepc
		load_x t0, 0( sp )
		csrw mepc, t0
		
		// 获取(恢复) 下个任务 的 mstatus
		load_x  t0, 29 * portWORD_SIZE( sp )
		csrw mstatus, t0
		
		// 恢复 各个寄存器
		load_x  x1, 1 * portWORD_SIZE( sp )
		load_x  x5, 2 * portWORD_SIZE( sp )
		...
		load_x  x31, 28 * portWORD_SIZE( sp )

		// 恢复 下个任务的 sp // 此时 恢复的 sp 中 保存的 是  运行状态的 函数堆栈 值
		addi sp, sp, portCONTEXT_SIZE
		
		// 返回任务
		mret
			// 该指令后,下一条指令就是 prvQueueReceiveTask 任务
__pop_
关注
专栏目录
QEMU 仿真RISC-V freeRTOS 程序
silencewly的专栏
08-27 1033
文章成功實現qemu 仿真RISC-V freeRTOS 程序
基于RISC-V的QEMU + FreeRTOS开发环境构建
qq_42357476的博客
10-15 1587
Ubuntu(22.04.1 LTS)中，基于RISC-V工具链，在QEMU上构建FreeRTOS，用以支持后续的仿真实验。
RISC-V特权架构 - 时钟中断处理
最新发布
百里杨的博客
08-12 858
经过对MTI和STI中断的处理分析，发现两者的查询处理逻辑，其实是一样的。其处理流程，总结为以下几个步骤（以XXI：检查确保XXI中断使能，且该中断被触发根据运行模式，检查全局中断开关检查mstatus.mie：禁用M全局中断，不处理：使能M全局中断，继续检查委托：不委托，陷入M：委托到S，陷入S检查mstatus.sie：禁用S全局中断，继续检查委托：不委托，陷入M：委托到S，不处理：使能S全局中断，继续检查委托：不委托，陷入M：委托到S，陷入S。
RISC-V FreeRTOS启动过程分析（基于qemu+gdb调试）
qq_33549208的博客
09-14 1444
最近在学RISC-V架构，有幸找到了一个非常好的课程《循序渐进，学习开发一个RISC-V上的操作系统》，学完后受益匪浅，但是课程上开发的操作系统毕竟只是教学用，想对比学习一下实际商用的RTOS的实现。FreeRTOS以前也用过，是一个非常流行的开源RTOS，所以选择了qume+FreeRTOS分析学习相关代码。本文先分析RISC-V + qume + FreeRTOS的启动流程。环境搭建可以参考。
Renode应用：在RISC-V核上运行FreeRTOS
牧羊女
10-26 5683
本篇记录通过Renode在RISC-V核上运行FreeRTOS demo的情况。本来不准备写这一篇，但是发现近期工作学习密度实在太大，上周工作的中间结果这周竟然完全想不起来了，不得不又花了一些时间从头摸索着重新配置了一遍，好记性是没指望了，只能依赖烂笔头。 该例中使用的是MiFive M2GL025开发板(当然，是通过Renode模拟的)，集成开发环境是SoftConsole，具体可以参考：RTOS Demo for RISC-V MiFive M2GL025 / Renode - FreeRTOS 一
RISC-V移植FreeRTOS
wo___fu的博客
05-30 983
重定义中断和异常接口函数，参数为。Machine Timer地址。
freertos任务调度机制深度分析（以RISC-V架构为例）
weixin_42031299的博客
11-29 2180
/就绪链表，configMAX_PRIORITIES是定义的当前支持最大的优先级，数字越大优先级越高//就绪链表有多个，每个优先级有一个就绪链表//两个都是挂起休眠任务的，之所以有两个是为了解决tickCount超过表示范围产生翻转//这是两个链表指针，用于指向上面的两个休眠链表//任务调度器挂起期间解除阻塞条件得到满足的阻塞任务，在任务调度器恢复工作后，//这些任务会被移动到就绪链表组中，变为就绪状态。//这个保存被删除的任务，等待空闲链表去回收资源。
移植 FreeRTOS 到 RISC-V S 模式和 U 模式实现运行模式隔离，运行在 M 模 secure monitor 上
07-24
在具有 secure monitor（M 模式）的 risc-v 软件平台上运行 freertos 能够实现一个硬件上运行多个 RTOS，不过目前市面上并没有对应的支持。 附件是将运行在 M 模式和 U 模式的 FreeRTOS 移植到了 S 模式和 U 模式，...
risc_v.rar_72T_risc-v_risc-v开发板_riscv-spec_riscv指令集pdf
07-15
RISC-V的开源性质也鼓励了开源编译器如GCC和LLVM的支持，以及各种操作系统（如Linux、FreeRTOS等）的移植。开发者可以利用这些资源进行从嵌入式应用到高性能计算的各种项目。 总的来说，这个压缩包提供了深入理解...
【RISC-V 实战篇】 将 FreeRTOS 运行在 RISC-V S 模式和 U 模式
最是书香能致远，腹有诗书气自华
03-19 1429
FreeRTOS-metal 是一个为 RISC-V 微控制器设计的实时操作系统，它结合了 FreeRTOS 和 Metal 库的优势，并提供了高效、可靠和可移植的解决方案，适用于各种嵌入式系统和应用程序。 FreeRTOS-metal 是运行在机器模式和用户模式，适用于大多数简单应用场景，不过对于需要运行多运行区域隔离的场景（比如运行多个 RTOS），则需要 FreeRTOS 运行在S-U 模式，M 模式运行监视软件，我们姑且称为FreeRTOS-metal-SU，这就是本文的成果。
RISC-V FreeRTOS异常处理及任务切换分析（基于qemu+gdb跟踪调试）
qq_33549208的博客
09-14 938
也就回到了进入异常前的任务，或者完成任务切换（这里FreeRTOS是实时操作系统，并不是只有在timer中断时才切换任务，比如高优先级任务被唤醒而发生抢占，或者当前运行的任务主动挂起都会触发任务切换）。为了观察prvQueueSendTask上下文的恢复情况，我们先在processed_source最后的mret指令处增加断点，继续运行到新增加断点处，此时理应恢复了prvQueueSendTask的上下文，那我们就再打印一次相关寄存器，与前一次打印的对比，可以看到是一模一样的。
FreeRTOS-RISCV：在FreeRTOS上测试simple-riscv的示例
02-12
适用于RISC-V的FreeRTOS 这是在FreeRTOS上测试的示例 建立 git clone --recursive https://github.com/kuopinghsu/FreeRTOS-RISCV cd FreeRTOS-RISCV && make 跑 要求：安装工具链。 请参阅srv32部分中的详细信息。 克隆并将FreeRTOS的演示复制到srv32'sw'文件夹。 该演示可以在srv32的RTL和ISS仿真器中运行。 请参阅对srv32的的详细信息。
FreeRTOS 10.4.3在RISCV(T-HEAD C906)平台上移植过程
tugouxp的专栏
01-26 3109
好记性不如烂笔头，记录点滴移植经历，一方面便于总结提炼，二是分享，让别人少走有些弯路。 搭建构建环境，准备利用melis上已经建好的环境，借”鸡“生”蛋".目标是移植FreeRTOS 系统，所以这部分不重点记录，总之，环境已建好。 用不用sbi? 暂时先用，后续优化掉，因为与Melis相比，FreeRTOS构建的系统相对简单很多，不用支持MMU，整个FreeRTOS系统加上应用都可以运行在M模式，sbi也就失去的存在的必要，但是还是决定先保留着，移植完成后再优化掉。主要考虑三点，1.环境和sbi之间有依
FreeRTOS 中 RISC-V-Qemu-virt_GCC 的 锁机制 分析
u011011827的博客
07-02 372
freertos riscv 锁机制
给risc-v标准内核适配freertos-kernel
xunxiaohui的博客
12-29 1470
描述 PS：自从freertos被亚马逊收购后添加了大量的云服务的支持，所以下面称呼为freertos-kernel.特指项目地址:https://github.com/FreeRTOS/FreeRTOS-Kernel 说点肺话 为什么不叫移植freertos-kernel呢？因为从下面freertos-kernel的发布历史可以看到，freertos内核从FreeRTOS V10.1.1 and FreeRTOS V10.2.0开始就支持risc-v了，但是这个版本对于64bit的risc-v的支持好像还
基于 qemu 的 riscv32架构的 freertos 体验 教程
u011011827的博客
09-01 3347
我在 freertos 最新版本中看到了 FreeRTOSv202107.00\FreeRTOS\Demo\RISC-V-Qemu-virt_GCC 准备搭环境体验一下 ,因为我后续要做类似的工作 --- 搭环境是比较麻烦的一件事, 我准备在 ubuntu-16.04.7 iso 做出的虚拟机上 做这件事 但是, 找了一些 源, 都找不到 qemu-system-riscv32 . 去官网下载 qemu-6.1.0 并编译 ,要求我装 python3.6 ,我去 源中找 python3.6 , 找不到.
[FreeRTOS] Using FreeRTOS on RISC-V Microcontrollers
kuankuan02的博客
07-30 2776
FreeRTOS 10.2.1版本开始，官方加入risc-v demo,并且增加目录source/portable/gcc/risc-v . 正式官宣对risc-v soc的支持，改动部分可以参考以下地址： https://www.freertos.org/Using-FreeRTOS-on-RISC-V.html 实际上对于risc-v soc的使用，很多用户早就可以运行于FreeR...
[RISCV]为RISC-V移植FreeRTOS系列之一 -- 目录结构
wangyijieonline的博客
11-13 6043
文章目录前言一、FreeRTOS是什么？二、RISC-V是什么？三、移植freertos1.下载freertos的最新源码2. 建立工程目录结构1, 关于Demo文件夹2, 关于Source文件夹3, 新建一个App文件夹总结 前言 写这篇文章的时候，我基本已经完成了这项工作了，花了一周的时间来把freertos porting到Andes公司的N25 riscv core上，本来其实是想支持国产的RT-Thread，但是奈何资料太少了，可能我后续会基于现有版本来继续porting一个rt-thread版
[RISCV]为RISC-V移植FreeRTOS系列之四 -- 中断与trap handler
wangyijieonline的博客
11-16 5014
前言 上回说到了我们已经把系统的心跳动起来了，但是这里面还有一个问题，我们都知道timer中断，中断的trap怎么来的呢。 这回就来解决这个事情。 作者：wangyijieonline 链接：https://blog.csdn.net/wangyijieonline/article/details/109721689 来源：CSDN 著作权归作者所有。商业转载请联系作者获得授权，非商业转载必须注明出处。 回顾一下官方Guide:Using FreeRTOS on RISC-V Microcontroll
一直freertos到risc-v
12-14
一旦完成了FreeRTOS到RISC-V的移植，就可以在RISC-V平台上运行嵌入式应用程序了。这样，开发者就可以充分利用RISC-V的开放性和灵活性，同时享受FreeRTOS提供的实时操作系统功能，构建高效、可靠的嵌入式系统。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值