commit 5fc902d56dee8741dd2a43278dff5b0a279f7e84
Author: Microindole <microindole@gmail.com>
Date:   Fri May 8 11:41:36 2026 +0800

    Reset repository for UEFI x86_64 reboot

diff --git a/.gitignore b/.gitignore
new file mode 100644
index 0000000..b8c663f
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1,9 @@
+build/
+*.o
+*.obj
+*.elf
+*.efi
+*.bin
+*.img
+*.iso
+*.log
diff --git a/README.md b/README.md
new file mode 100644
index 0000000..09d82f4
--- /dev/null
+++ b/README.md
@@ -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. 在屏幕上输出一行可见文本
+
+做到这一步后，再继续扩展。