检查主线系统首次启动日志
离线检查只能证明镜像里“放了什么”，串口日志才能证明 T527 实际“执行了什么”。本次烧录后，Avaota A1 已经从主线 SPL 一直运行到 Buildroot 登录界面，完整跨过五次控制权交接。
检查五个启动阶段
不要从几百行日志中逐字寻找错误。先确认下面五个里程碑是否按顺序出现，再回到缺失的那一段分析。
| 阶段 | 本次实机证据 | 这行证明什么 |
|---|---|---|
| SPL | U-Boot SPL 2026.07-dirty、DRAM: 4096 MiB | BootROM 接受 eGON 头，SPL 与 DRAM 已运行 |
| TF-A | BL31: v2.12.0(debug):b5de74a68 | FIT 中的 BL31 已装载并执行 |
| U-Boot | Model: Avaota A1、Found /extlinux/extlinux.conf | 板级 DTB、生存环境、FAT 和启动项可读 |
| Linux | Linux version 7.2.0-avaota-a1-mainline | U-Boot 已装载 Image、Linux DTB 并完成跳转 |
| Buildroot | Avaota A1 mainline Linux / Buildroot 2026.05.1 | 根文件系统已挂载，init 已进入登录阶段 |
这五行共同出现，才能把它称为“主线系统启动成功”。只看到 U-Boot 提示符，不能证明 Linux 能加载；只看到 Linux 版本，也不能证明根文件系统能挂载。
SPL 到 U-Boot：核对版本与启动参数
本次启动日志中的 LYNX_ 行与当前 U-Boot 二进制内的字符串、构建时间完全一致：
U-Boot SPL 2026.07-dirty (Sep 01 2026 - 23:27:38 -0400)
DRAM: 4096 MiB
LYNX_RECOVERY_FEL: armed after boot device 2
Trying to boot from MMC2
LYNX_MMC_SAFE_IO: mmc=2 f_max=25000000 b_max=128
LYNX_MMC_FORCE_USER: boot1_ret=0 cached_hwpart=1
LYNX_MMC_FORCE_USER: user_ret=0 after_part_config=0x00 cached_hwpart=0
LYNX_MMC_DIAG: mode=1 part=0 base=0x60 offset=0x10 final=0x70
LYNX_MMC_DIAG: read sector=0x70 blksz=512
NOTICE: BL31: v2.12.0(debug):b5de74a68
这段日志依次回答了四个问题：eMMC 使用 MMC2、读取参数为 25 MHz/4-bit/128 块、硬件分区已回到 User Area、FIT 的最终扇区是 0x70。随后出现 BL31，说明这四项不是仅仅被设置，而是已经支撑了一次成功读取与跳转。
当前对应的 u-boot-sunxi-with-spl.bin SHA-256 为：
0d405263a5ea10bf97c64e5f07c5b04b11a484372ce1c8fd769980ca4e5b70c3
这个哈希只标识当前 U-Boot 组合文件，不能替代 FES loader 与整盘 raw 的哈希。
U-Boot 到 Linux：确认 Image 与 DTB 已加载
U-Boot 2026.07-dirty (Sep 01 2026 - 23:27:38 -0400)
CPU: Allwinner A523 (SUN55I)
Model: Avaota A1
DRAM: LYNX_RAM_TOP_SAFE: detected_top=0x140000000 usable_top=0x50000000
4 GiB
LYNX_MMC_SAFE_IO_DM: mmc=2 f_max=25000000 b_max=128 force_width=4
Scanning mmc 1:1...
Found /extlinux/extlinux.conf
Retrieving file: /Image
Retrieving file: /sun55i-t527-avaota-a1.dtb
Starting kernel ...
b_max=128 把 Image 的读取过程拆成 64 KiB 小请求，避免默认的 65,535 块大请求超过控制器等待时间。日志越过 Image 与 DTB 加载并出现 Starting kernel ...，说明 U-Boot 已经完整读出启动文件。
Linux 到 Buildroot：根文件系统来自 eMMC
内核日志给出了从控制器 probe 到挂载根分区的连续证据：
sunxi-mmc 4022000.mmc: initialized, max. request size: 2048 KB
Waiting for root device /dev/mmcblk1p2...
mmc1: new high speed DDR MMC card at address 0001
mmcblk1: mmc1:0001 CJNB4R 58.2 GiB
mmcblk1: p1 p2
EXT4-fs (mmcblk1p2): recovery complete
EXT4-fs (mmcblk1p2): mounted filesystem
VFS: Mounted root (ext4 filesystem) on device 179:2.
进入系统后再次核对：
$ uname -a
Linux avaota-a1 7.2.0-avaota-a1-mainline ... aarch64 GNU/Linux
$ cat /proc/cmdline
console=ttyS0,115200 earlycon root=/dev/mmcblk1p2 rootwait rw fsck.repair=yes net.ifnames=0
$ mount | grep ' on / '
/dev/root on / type ext4 (rw,relatime)
Linux 还识别出 mmcblk1boot0、mmcblk1boot1 和 4 GiB DRAM。这证明 U-Boot 的低地址运行限制没有缩小 Linux 看到的物理内存。
FAIL 不一定表示整机启动失败
用户空间随后出现：
Starting network: Waiting for interface eth0,eth1 to appear............... timeout!
run-parts: /etc/network/if-pre-up.d/wait_iface: exit status 1
FAIL
Starting crond: OK
Starting dropbear sshd: OK
这里的 FAIL 属于网络启动脚本：它等待网卡就绪超时。系统仍继续启动 crond、Dropbear 并给出登录提示，因此它不是内核、根文件系统或整条启动链失败。后续 ip link 能看到 eth0、eth1 和 usb0，但链路、PHY 与网络配置仍要单独验证。
这也是阅读串口日志时必须养成的习惯：先确定错误属于哪个进程或阶段，再判断它是否阻断后续启动。
汇总首次启动结果
| 检查项 | 当前状态 | 依据 |
|---|---|---|
| 主线 SPL → TF-A → U-Boot | 已通过一次实机启动 | 连续版本与 LYNX_ 日志 |
| U-Boot 从 FAT 加载 Image/DTB | 已通过一次实机启动 | Retrieving file 后进入内核 |
| Linux 挂载 eMMC ext4 根分区 | 已通过一次实机启动 | mmcblk1p2 与 VFS 日志 |
| Buildroot 登录 | 已通过一次实机启动 | 登录提示与 shell 命令 |
可以下载 本次串口关键记录，按照五个启动阶段与自己的串口输出逐段对照。下一节继续验证完全断电后的 eMMC 启动稳定性。