| boot | ||
| docs | ||
| include | ||
| kernel | ||
| scripts | ||
| .gitignore | ||
| Makefile | ||
| README.md | ||
Tianole
新的起点。这个仓库现在不保留旧实现，先把目标机器、开发环境、技术路线和最小步骤固定下来，避免再次在错误方向上堆代码。
当前结论
- 语言：第一版用
C - 架构：
x86_64 - 启动方式：
UEFI - 主开发环境：
WSL2 - 日常验证：先
QEMU + OVMF - 真机验证：先
U 盘 UEFI启动 - 最终目标：在自己的笔记本上以独立启动项或可控方式启动，不先破坏现有
Windows 11 + Linux Mint + GRUB
为什么现在不用旧代码
旧实现的问题不是“有几个 bug”，而是路线已经和目标真机错位：
- 旧项目是
32位 + Multiboot + GRUB + qemu-system-i386 - 你的目标机器是现代
UEFI + GPT + x86_64 - 旧项目已经铺到任务、FAT16、ATA PIO、用户态切换，但底座仍是老 PC 路线
- 继续修补会持续消耗精力在错误底座上
所以现在直接重开，比在旧代码上修修补补更省。
这台机器已经确认的信息
- 当前日期环境：
2026-05-08 - 机器：
LENOVO 21HX - CPU：
13th Gen Intel Core i5-13500H - 核心/线程：
12核16线程 - 内存：
16 GB - 显卡：
Intel Iris Xe Graphics - 磁盘：
1 TB NVMe SSD - 固件模式：
UEFI - 分区表：
GPT - BIOS 版本：
LBCN26WW - BIOS 日期：
2024-08-23 - 当前系统状态：你现在在
Windows 11，机器上同时有Linux Mint - 启动情况：GRUB 由
Mint管理，你现在只是从该多启动环境进入了 Windows - 额外观察：系统报告
HypervisorPresent = True - 未确认项：
Secure Boot状态未成功读出，后续真机启动自制 OS 时必须单独检查
这些信息意味着什么
- 不要走
BIOS + MBR + 16位 boot sector教程路线 - 不要再把
32位当主线 - 第一阶段不要碰真实 GPU 驱动，先用
UEFI GOP framebuffer - 第一阶段不要碰真实
NVMe驱动 - 第一阶段不要急着做复杂用户态
- 真机阶段不要一开始去改现有
GRUB或覆盖 EFI 启动链
为什么现在选 C，不选 Rust
你的条件是：
- 想长期做
- 但会断断续续
- 目标是最后装到自己的真机
- 设计思路参考 Linux
在这个组合下，C + x86_64 + UEFI 的阻力最低。
原因：
- 回坑成本低
- Linux 资料、历史实现、底层文档更贴近 C
- 你要适配的核心问题是
UEFI / GPT / framebuffer / 内存管理 / 中断，不是语言特性 - Rust 不是不能做，但更容易把精力花在
no_std、启动框架和抽象边界上
结论：
- 第一版内核主体：
C - 少量汇编：只保留最必要的入口和极少数底层切换
- 以后如果需要，再局部引入 Rust
为什么用 WSL2
主开发环境建议：
WSL2 + Ubuntu
原因：
gcc/clangmakenasmlldobjdump/readelfqemumtoolsovmf
这套工具在 Linux 环境里更顺，资料也基本默认 Linux。
Windows 仍然保留这些职责：
- 日常文件管理
- 处理下载
- 需要时管理 U 盘
- 重启进入 BIOS/启动菜单
- 真机测试前的辅助操作
长期工作流：
- 在
WSL2中写代码、编译、跑QEMU - 需要更底层的镜像/介质实验时，可以切去
Mint - 真机验证优先走
U 盘 UEFI启动 - 系统稳定后，再决定是否集成进本机磁盘启动项
目标路线
第一阶段只做最小系统：
UEFI启动成功- 获取内存映射
- 初始化
framebuffer - 屏幕输出
- 建立基础页表
- 基础中断框架
- 一个极简内核循环
这一阶段完成后，再考虑：
- 物理内存分配器
- 简单堆分配
- 键盘输入
- 简单 shell
- ELF 加载
- 用户态
- 文件系统
WSL2 中建议的基础环境
以 Ubuntu 为例：
sudo apt update
sudo apt install -y \
build-essential \
clang \
lld \
nasm \
make \
cmake \
qemu-system-x86 \
ovmf \
mtools \
dosfstools \
gdisk \
xorriso \
gdb \
python3
可选检查：
gcc --version
clang --version
ld.lld --version
nasm -v
qemu-system-x86_64 --version
新仓库的起步步骤
切到 WSL 后，建议按这个顺序开始：
- 在
WSL中打开这个仓库 - 保持仓库目标单纯，只做
C + UEFI + x86_64 - 先搭最小目录结构
- 先让一个最小
UEFI程序在QEMU + OVMF下跑起来 - 再把它拆成
bootloader / kernel或直接决定最小加载方案 - 先证明启动链可控，再扩内核
建议的最小目录结构
第一版建议从非常小的结构开始：
tianole/
README.md
.gitignore
Makefile
boot/
kernel/
include/
scripts/
build/
先不要一开始就拆出：
fs/drivers/mm/userland/lib/
等真正需要时再拆，不要先造目录架子。
真机测试原则
你这台机器是 Windows 11 + Linux Mint 双系统，并且已有 GRUB 启动环境，所以真机测试要克制：
- 第一阶段只在
QEMU + OVMF验证 - 第二阶段只从
U 盘启动 - 第三阶段再考虑新增 UEFI 启动项
- 不要一开始改当前磁盘上的
GRUB配置 - 不要一开始尝试覆盖现有 EFI 分区中的关键文件
当前最重要的技术边界
- 做现代 PC，不做老式 BIOS 教程项目
- 先做可启动、可显示、可调试
- 先不要做“看起来很完整”的模块铺设
- 先把启动链做对，再谈进程、文件系统、用户态
- 任何新代码都要服务于真机
UEFI x86_64目标
下一步
切到 WSL 后，下一步不是继续讨论语言，而是直接开始搭最小骨架：
- 建立
Makefile - 建立最小
boot/与kernel/ - 跑通
QEMU + OVMF - 在屏幕上输出一行可见文本
做到这一步后，再继续扩展。