Reset repository for UEFI x86_64 reboot
This commit is contained in:
commit
5fc902d56d
9
.gitignore
vendored
Normal file
9
.gitignore
vendored
Normal file
@ -0,0 +1,9 @@
|
||||
build/
|
||||
*.o
|
||||
*.obj
|
||||
*.elf
|
||||
*.efi
|
||||
*.bin
|
||||
*.img
|
||||
*.iso
|
||||
*.log
|
||||
230
README.md
Normal file
230
README.md
Normal file
@ -0,0 +1,230 @@
|
||||
# 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. 在屏幕上输出一行可见文本
|
||||
|
||||
做到这一步后，再继续扩展。
|
||||
Loading…
Reference in New Issue
Block a user