100ASK T113S3 Pro 主线系统构建与打包总览
本章目标
在分别阅读 U-Boot、Linux 和 Buildroot 适配细节之前，先建立一张完整的构建地图：输入从哪里来、各组件由谁编译、产物如何组合、哪些文件用于运行、哪些文件只用于安装，以及成功构建为什么不能直接等同于上板成功。
一条命令背后的工作
完成Ubuntu 20 开发环境与源码准备后，统一构建入口是：
cd "$HOME/workspace/t113-mainline-work/DshanPI-T113xMainlineLinux"
./scripts/build-everything.sh
这个脚本不是简单地把几个二进制文件复制到一起。它会测试并构建 OpenixCLI，准备固定版本的 Buildroot，应用板级配置和永久补丁，构建 U-Boot、Linux、根文件系统和 RAM installer，最后生成带哈希和加载计划的 FEL 安装包。
总体数据流
这张图中有两条容易混淆的线：
- 构建线：源码和配置生成 SPL、U-Boot、内核、DTB、UBIFS、UBI、FIT 和安装包；
- 安装线：OpenixCLI 把 SPL、U-Boot 和安装器加载到 RAM，再由板端 Linux installer 写入 SPI NAND。
OpenixCLI 本身不直接把 sys.ubi 当作裸 NAND 数据写入，也不负责宣告板端安装成功。
输入分层
| 输入层 | 主要内容 | 固定方式 |
|---|---|---|
| 主机工具 | GCC、Make、Python 3、Rust/Cargo、libusb | Ubuntu 20 环境验收 |
| 工作流源码 | OpenixCLI、T113 主线系统仓库 | 明确功能分支和 Git commit |
| 上游源码 | Buildroot、Linux、U-Boot | manifests/sources.lock 与归档哈希 |
| 板级配置 | defconfig、DTS、内核/U-Boot fragment | 主线仓库版本控制 |
| 永久补丁 | U-Boot 和 Linux patch series | 干净源码重放并校验 |
| 封装规则 | FIT ITS、UBI 配置、payload 布局、加载计划 | board/ 与 scripts/ 中的脚本 |
任何一层变化都可能改变最终哈希。旧产物已经通过硬件验证，不代表新提交构建出的文件自动继承该结论。
阶段一：准备固定 Buildroot 树
主线仓库将 Buildroot 作为统一构建框架。make bootstrap 或完整构建脚本会：
- 克隆 Buildroot；
- 切换到固定 commit；
- 校验 commit 和下载输入；
- 安装
configs/dshanpi_t113s3pro_nand_defconfig； - 安装
board/dshanpi/t113s3pro/板级目录。
Buildroot 在这里负责组织工具链和各目标组件，但板级移植内容仍由本项目仓库维护。
阶段二：构建主线 U-Boot
U-Boot 构建应用板级补丁和 fragment，生成两类用途不同的文件：
| 产物 | 用途 |
|---|---|
| FEL SPL | 在 SRAM 中运行，初始化 DDR 后返回 BootROM FEL |
| NAND SPL | 从 SPI NAND 冷启动，加载 U-Boot proper |
| U-Boot proper | 初始化后续外设并从 boot 分区读取 boot.itb |
| 冗余写入镜像 | 按 NAND 分区和冗余规则提供给 installer |
这一阶段必须保持 SPL 和 U-Boot proper 来自同一次构建。具体适配点见主线 U-Boot 适配。
阶段三：构建主线 Linux
Linux 构建输出内核镜像和板级 DTB，同时包含两套运行上下文：
- 正常系统：从 SPI NAND 启动并挂载
ubi0:rootfs； - RAM installer：从 DRAM 中启动，识别 MTD、处理 UBI，并写入目标分区。
两者共用主线内核基础，但 installer 使用专用 initramfs、保留内存和启动参数。具体内容见主线 Linux 适配。
阶段四：生成 Buildroot 根文件系统
Buildroot 用户空间生成：
- 正常启动使用的
rootfs.ubifs； - 可写入
sys分区的sys.ubi； - installer 所需的 BusyBox、MTD、UBI 和校验工具；
- 串口登录和系统标识文件。
UBIFS 参数必须与 W25N02KV 的页、OOB、擦除块及 Linux UBI 参数一致。详见Buildroot 根文件系统适配。
阶段五：制作 FIT 和 NAND payload
封装脚本组合出两种 FIT：
| 文件 | 包含内容 | 使用阶段 |
|---|---|---|
boot.itb | 正常内核、DTB 和启动配置 | SPI NAND 正常冷启动 |
fel-installer.itb | installer 内核、DTB 和 initramfs | FEL RAM 安装阶段 |
随后把 SPL、U-Boot、boot.itb 和 sys.ubi 按固定 NAND 布局描述为 payload。payload 不是供 dd 写入的 256 MiB 裸镜像，而是由 installer 按 MTD、坏块、OOB 和 ECC 规则处理的有界输入。
分区和地址关系见镜像与分区设计。
阶段六：生成 FEL 安装 bundle
最终输出目录：
out/t113s3pro-mainline-fel/
├── fel-sunxi-spl.bin
├── fel-u-boot.bin
├── fel-installer.itb
├── boot.itb
├── sys.ubi
├── spl-redundant.bin
├── uboot-redundant.bin
├── fel-payload.tar.gz
├── fel-payload.part-00 ...
├── fel-payload-layout
├── FEL_ARTIFACTS
└── FEL_SHA256SUMS
scripts/flash-mainline-fel.sh 在执行时还会根据这些文件生成 openix-mainline-plan.json。不同提交下的实际辅助文件可能增加，操作时以 FEL_ARTIFACTS、运行时计划和校验清单为准。OpenixCLI 必须先验证角色、地址、长度和 SHA-256，再开始加载。
阶段七：本地门禁
构建脚本最后运行本地验收，包括：
- 固定源码和补丁是否一致；
- SPL eGON 头、长度和 checksum；
- U-Boot 加载地址、UART3 和环境配置；
- Linux、DTB、FIT、UBI 和 payload 结构；
- OpenixCLI 地址计划和角色；
- shell/Python 辅助脚本语法；
- 历史硬件证据与当前 manifest 的状态关系。
预期汇总必须是 fail=0。完整执行方法见完整编译规程。
构建、安装和验收的边界
| 状态 | 能证明什么 | 不能证明什么 |
|---|---|---|
| 编译成功 | 编译器完成目标文件生成 | 产物能在板上运行 |
| 本地门禁通过 | 文件结构、哈希和静态约束一致 | installer 已执行 |
| RAM handoff 完成 | SPL/U-Boot/installer 已加载到 RAM | SPI NAND 已写入 |
| installer complete | 板端完成写入和读回 | 完全断电后能冷启动 |
| 冷启动通过 | 当前哈希可从 SPI NAND 启动 | 其他 NAND 或量产批次同样通过 |
历史上确实出现过“本地门禁全部通过但 installer 没有输出”的产物，因此这五个状态不得合并成一个“成功”。真实过程见真实调试记录。
阅读下一章
理解总体数据流后，按组件顺序继续阅读：