Dvorak
Dvorak

Dvorak Chen

All Posts in 2025.1

26
JAN

上一篇的页表错误修正

在页表实现的修正过程中作者发现了一个关键性的认知误区——物理地址与物理页号的混淆导致页表构建失败。物理页帧作为4K大小的内存单元其地址本质是物理地址而页表项中44位的PPN字段需要的是物理地址右移12位后的页号而非直接填入地址本身这种差异在RISC-V手册第10.3.2节的页表转换流程图中隐藏着重要线索。当试图将物理地址直接写入PPN字段时实际上破坏了地址分层结构这种错误源于对PPN[0]与PPN[1]分段标识的过度解读。这种认知偏差暴露出操作系统底层开发中概念边界模糊的普遍困境——当文档以分段方式展示物理地址时是否必然暗示着非连续的页号处理？保留错误代码的原始版本既是对开发成本的妥协也暗示着错误本身的价值：它是否揭示了操作系统教学中常见的认知陷阱？页表实现的复杂性是否恰恰来源于这种看似简单实则精密的地址转换逻辑？当开发者面对手册中抽象的地址分解图时又该如何避免陷入概念混淆的泥潭？--Qwen3

RISC-V risc-v-architecture page-table-implementation physical-address ppn-misunderstanding physical-page-frame error-correction
16
JAN

(deprecated)使用 Rust 为 RISC-V 设置页表

文章详细描述了RISC-V架构下页表的构建与satp寄存器配置过程。通过RootPageTable结构管理整张页表及其所有页帧和分配器，以LevelPageTable结构处理具体页表项的访问与创建，将4k页表内存视为512个PTE切片。PTE结构体以C语言布局存储64位页表项，通过检查V位判断有效性并动态分配下级页表。Map方法通过MapBlock参数（含虚拟页号、映射类型和权限）实现三级页表的层级映射，支持恒等映射（虚拟地址直接对应物理地址）和页帧映射两种模式。最终通过satp_token方法将根页表物理地址与RISC-V模式（8<<60）组合生成satp寄存器值，并通过汇编sfence.vma指令刷新转译旁路缓存完成页表启用。--Qwen3

Rust RISC-V riscv memory-management page-tables pte-construction satp-register rust-memory
03
JAN

Rust 编写裸机代码使用链接器脚本

这篇文章探讨了在Rust中编写Risc-V裸机代码时如何通过自定义链接器脚本控制内存布局与符号定义。通过链接器脚本可以精确指定代码段数据段的位置和对齐方式例如用`ALIGN(4K)`确保内存4KB对齐或通过`.text.entry`定义入口段位置这种细粒度控制让开发者能优化程序的内存占用和执行效率。文章通过示例展示了如何定义`sbss`和`ebss`符号来标记`.bss`段的起始与结束地址并揭示了这些符号在Rust代码中如何被使用以获取内存布局信息。当开发者观察到`ARR`数组的地址恰好落在`.bss`段范围内时不禁会思考如何通过调整链接器脚本进一步优化全局变量的存储策略。文章还抛出了一个值得深究的问题：如果将`.rodata`段与`.data`段的对齐方式改为非4KB会否影响程序性能？更进一步当链接器脚本中定义的`.skernel`和`.ekernel`符号用于计算整个程序的大小时是否意味着我们可以用这些符号构建更灵活的内存管理机制？通过自定义符号和段布局开发者不仅能够掌控程序的物理内存映射还能为后续的内存保护或动态加载功能打下基础。这种从链接层面介入程序构建的方式是否能让Rust在嵌入式领域实现更高效的资源利用？--Qwen3

Rust RISC-V memory-management linker-script rust-programming section-alignment symbol-table print-implementation
02
JAN

使用 Rust 编写 Risc-V 裸机代码

本文探讨了如何利用Rust语言构建Risc-V架构的裸机程序揭示了脱离操作系统支持的底层开发方法。通过解析Rust工具链的交叉编译机制重点阐述了riscv64gc-unknown-none-elf目标平台的特殊性及其四部分命名规则背后的逻辑。文章展示了从环境配置到代码构建的完整流程包括通过rustup添加目标平台组件使用llvm工具链配置链接器脚本以及在CARGO配置中指定ELF格式的链接参数。核心开发实践中no_std和no_main宏的应用突破了常规Rust开发范式迫使开发者直接面对硬件层面的编程挑战而自定义panic处理函数则体现了对程序异常控制流的完全掌控。这种开发模式不仅需要重新理解Rust的编译机制更要求开发者思考如何在没有标准库支持的环境下构建基础功能。当代码执行流从_start函数开始时每一个内存操作都直面硬件真实映射这是否意味着Rust的类型安全特性在此场景下会遇到新的边界？当开发者亲手编写链接器脚本时如何平衡内存布局的灵活性与程序稳定性？这些思考或许能帮助我们更深刻地理解系统底层运行机制。--Qwen3

Rust RISC-V embedded-systems bare-metal cross-compilation no-std