tianole/README.md

231 lines
5.7 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# 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/clang`
- `make`
- `nasm`
- `lld`
- `objdump/readelf`
- `qemu`
- `mtools`
- `ovmf`
这套工具在 Linux 环境里更顺,资料也基本默认 Linux。
Windows 仍然保留这些职责:
- 日常文件管理
- 处理下载
- 需要时管理 U 盘
- 重启进入 BIOS/启动菜单
- 真机测试前的辅助操作
长期工作流:
1.`WSL2` 中写代码、编译、跑 `QEMU`
2. 需要更底层的镜像/介质实验时,可以切去 `Mint`
3. 真机验证优先走 `U 盘 UEFI` 启动
4. 系统稳定后,再决定是否集成进本机磁盘启动项
## 目标路线
第一阶段只做最小系统:
1. `UEFI` 启动成功
2. 获取内存映射
3. 初始化 `framebuffer`
4. 屏幕输出
5. 建立基础页表
6. 基础中断框架
7. 一个极简内核循环
这一阶段完成后,再考虑:
1. 物理内存分配器
2. 简单堆分配
3. 键盘输入
4. 简单 shell
5. ELF 加载
6. 用户态
7. 文件系统
## WSL2 中建议的基础环境
以 Ubuntu 为例:
```bash
sudo apt update
sudo apt install -y \
build-essential \
clang \
lld \
nasm \
make \
cmake \
qemu-system-x86 \
ovmf \
mtools \
dosfstools \
gdisk \
xorriso \
gdb \
python3
```
可选检查:
```bash
gcc --version
clang --version
ld.lld --version
nasm -v
qemu-system-x86_64 --version
```
## 新仓库的起步步骤
切到 `WSL` 后,建议按这个顺序开始:
1.`WSL` 中打开这个仓库
2. 保持仓库目标单纯,只做 `C + UEFI + x86_64`
3. 先搭最小目录结构
4. 先让一个最小 `UEFI` 程序在 `QEMU + OVMF` 下跑起来
5. 再把它拆成 `bootloader / kernel` 或直接决定最小加载方案
6. 先证明启动链可控,再扩内核
## 建议的最小目录结构
第一版建议从非常小的结构开始:
```text
tianole/
README.md
.gitignore
Makefile
boot/
kernel/
include/
scripts/
build/
```
先不要一开始就拆出:
- `fs/`
- `drivers/`
- `mm/`
- `userland/`
- `lib/`
等真正需要时再拆,不要先造目录架子。
## 真机测试原则
你这台机器是 `Windows 11 + Linux Mint` 双系统,并且已有 `GRUB` 启动环境,所以真机测试要克制:
1. 第一阶段只在 `QEMU + OVMF` 验证
2. 第二阶段只从 `U 盘` 启动
3. 第三阶段再考虑新增 UEFI 启动项
4. 不要一开始改当前磁盘上的 `GRUB` 配置
5. 不要一开始尝试覆盖现有 EFI 分区中的关键文件
## 当前最重要的技术边界
- 做现代 PC不做老式 BIOS 教程项目
- 先做可启动、可显示、可调试
- 先不要做“看起来很完整”的模块铺设
- 先把启动链做对,再谈进程、文件系统、用户态
- 任何新代码都要服务于真机 `UEFI x86_64` 目标
## 下一步
切到 `WSL` 后,下一步不是继续讨论语言,而是直接开始搭最小骨架:
1. 建立 `Makefile`
2. 建立最小 `boot/``kernel/`
3. 跑通 `QEMU + OVMF`
4. 在屏幕上输出一行可见文本
做到这一步后,再继续扩展。