Quard_D的博客

在之前我的一篇博客——《kgdb调试linux内核以及驱动模块》中简要描述如何配置kgdb进行内核以及驱动模块调试，这种方法既适用于qemu仿真环境也适用于真实的物理开发板，但对于做早期cpu core bridge up时未必能在物理设备上搭建好稳定可靠的kgdb环境。一般来讲使用qemu仿真来发现一些早期软件问题是有一定的帮助的，因此本文将描述，借助qemu的gdbsever模式，在仿真环境上更早的介入gdb工具进行非常底层的debug。本文实验环境依然为qemu搭建的riscv64模拟器环境，笔者之前

gcc编译选项pg在嵌入式profile中应用问题引入首先说明下，本文主要是描述下使用gcc的-pg编译选项在嵌入式的裸机或RTOS系统环境下实现一些函数级别的profile或者做代码覆盖率测试甚至实现trace功能。关于这个编译选项在GCC文档有描述，但是这里要注意一点，该选项一般来讲是配合glibc中的gprof实现完备且较为复杂的性能跟踪，而众所周知在MCU级别的嵌入式开发环境往往没有操作系统加持，仅有RTOS甚至是裸机环境，因此本文提出一种简易的可以在裸机环境实现简单但有效的trace实现思路。

使用qemu运行riscv64 linux本文编写于2021.6.6，经笔者测试所述编译配置流程均正确，如若出现错误，请检查各组件版本是否和笔者使用的一致。附：各组件版本号为linux-5.10.42，busybox-1.33.1，U-Boot 2021.04，OpenSBI v0.9，qemu-5.2.0，riscv64–glibc–bleeding-edge-2020.08-11.编译u-boot，生成u-boot.bin文件make CROSS_COMPILE=/opt/riscv64--gli

问题引入最近在使用某个版本的交叉编译工具链gcc时发现一个问题，示例如下：首先创建一个lto.c文件，内容如下：int issue_func(int a0, int a1){ return a0+a1;}创建main.cextern int issue_func(int a0, int a1);int main(){ return issue_func(5,6);}然后按照如下方式编译代码riscv-nuclei-elf-gcc -flto -o lto.o -

文章目录GD32VF103移植SVSTEMVIEWSystemView移植源文件加入工程修改freertos源码添加串口移植修改systemview配置完成移植GD32VF103移植SVSTEMVIEW最近兆易推出了基于RISCV的MCU－GD32VF103，得到了一个GD32VF103C-START 学习板，以前只用过arm内核mcu,从没用过RISCV内核,打算玩一下这块板子。这次打算移植...