uefi-arm64：通用 arm64 UEFI 机器

uefi-arm64 是 arm64 侧的通用系统：一份镜像服务于固件是 UEFI + ACPI 的 arm64 机器。它携带了 virtio 之外的通用硬件驱动——但它的全部 证据仍然只有 QEMU aarch64 virt。携带驱动不等于有证据证明某台机器能启动。 状态以状态表为准。

概况

项	值
架构	arm64
启动链	UEFI 固件（注册了开发启动锚）→ 签名的 EFI/BOOT/BOOTAA64.EFI → 计数启动项 → 签名 UKI → 认证的 native init → SYSTEM → 签名的 verity root/support → systemd
固件形态	efi（引导器在 ESP 内）
分区	ESP / SYSTEM / DATA
内核	主线 stable，与 uefi-x64 固定同一个 tag，故首次启动失败时不会分不清是移植问题还是内核版本问题
支持层级	bring-up（QEMU 参考）
启动保证等级	I1

启动链里没有厂商 blob，因为没有厂商——这是这块板存在的理由之一。

硬件与功能状态

功能	状态	说明
容器（Podman）	随镜像发布	BOARD_FEATURES="containers"
virtio-blk / virtio-net	QEMU 下已验证	全部证据都出自这条路径
SATA（AHCI）	内核内建，携带但未合格	从未在实体机器上跑过
NVMe	内核内建，携带但未合格	—
USB 存储（xHCI / EHCI）	内核内建，携带但未合格	—
常见网卡（e1000、igb、igc、ixgbe、r8169、tg3、mlx5、aqtion）	以模块携带，未合格	网络不在挂载 root 的路径上，模块从签名的 support 镜像加载
MMC / SD / eMMC	刻意不支持	完全没有 MMC 驱动：从平台 MMC 控制器启动的机器是另一块硬件板，不是这份镜像
RTC	内核内建（PL031、EFI）	QEMU 下可用
Wi-Fi / 蓝牙	无	镜像里没有 bluez、wpasupplicant、hostapd
状态灯、CAN、USB gadget、硬件初始化	无	BOARD_HWINIT_CONFS=""、BOARD_FIRMWARE_FILES=""
物理恢复动作	无	BOARD_RECOVERY_ACTIONS=""，凭据恢复与恢复出厂在这块板上一律被拒

驱动集是被强制的，不是碰运气：kernel/config/uefi-arm64.required 列了 122 个符号， 解析后的配置少一个就构建失败。代价也记着：232 个内核模块，Image 24.5 MB。

status: board-dependent — evidence: mica-build:boards/uefi-arm64/evidence.json, mica-build:boards/uefi-arm64/board.env, mica-build:boards/uefi-arm64/kernel/config

分区布局

分区	角色	起点	大小
esp	FAT，卷标 MICAESP	1 MiB	512 MiB
system	ext4	513 MiB	1024 MiB
data	ext4	1537 MiB	256 MiB（首次启动扩展到介质大小）

root/support 组件是 SYSTEM 上的不可变文件，UKI 在 ESP 上；只有 DATA 在首次启动时 增长。/var 及其骨架保持只读。

控制台

只有一个控制台：PL011 UART，console=ttyAMA0,115200n8。刻意没有 tty0—— aarch64 virt 没有 VGA 也没有 framebuffer，写 console=tty0 就是给一个没有设备的 控制台起名字。

获取镜像

产品是 uefi-arm64.basic（默认）与 uefi-arm64.full（带容器），各自发布为 uefi-arm64.<variant>.<YYYYMMDD-HHMM>，镜像文件名 mica-uefi-arm64.<variant>-<YYYYMMDD-HHMM>.img.gz。

刷机

在 QEMU 里。 把镜像解压为 disk.img 然后启动：

cp /usr/share/AAVMF/AAVMF_VARS.fd vars.fd
qemu-system-aarch64 -machine virt -cpu max -m 1024 -smp 2 -nographic -no-reboot \
  -device i6300esb -watchdog-action reset \
  -netdev user,id=net0,hostfwd=tcp:127.0.0.1:8080-:8080 -device virtio-net-pci,netdev=net0 \
  -drive if=pflash,format=raw,unit=0,readonly=on,file=/usr/share/AAVMF/AAVMF_CODE.secboot.fd \
  -drive if=pflash,format=raw,unit=1,file=vars.fd \
  -drive if=none,id=disk0,format=raw,file=disk.img \
  -device virtio-blk-pci,drive=disk0,bootindex=0

guest 的控制台是 PL011 且只有这一个，需要 i6300esb 看门狗，RTC 来自 PL031 或 EFI。在 amd64 宿主机上每条指令都是模拟执行的，启动要按分钟计。验收套件是在注册了发布证书、开启 Secure Boot 的情况下运行这条命令的；像这里这样用原样的变量存储，还没有跑过。取镜像、开启 Secure Boot 与排障见 刷写第 4 节。

写到实体 arm64 机器上（未验证）。 与 uefi-x64 同理：整盘写入，机器的固件须是带 ACPI 的 UEFI，并且要么信任该发布的启动证书，要么关闭 Secure Boot。没有任何实体 arm64 机器被 验证过。

status: unsupported

首次启动

与 uefi-x64 相同：早期 init 验证部署，DATA 扩容，健康门确认，设备在 8080 端口提供 Web 控制台和 API，在有人设置管理员密码之前处于未认领状态 （首次启动）。

更新

发布 full、root、kernel 三种归档。QEMU 里跑过 root-only、kernel-only 与组合 更新，包括三次健康失败后退回保留部署、固件与身份不变。见 更新与回滚。

恢复

• 可用：只读诊断、手动回滚、配置重置、应用数据重置、整盘重写镜像。
• 不可用：凭据恢复、恢复出厂（无物理在场断言）。
• 这块板的“恢复”就是在宿主上重写磁盘镜像：能写这个镜像文件的宿主已经等于换了设备， 所以没有带内恢复需要保护。

见恢复。

已知限制

• arm64 guest 在当前 amd64 测试宿主上以 TCG 运行，时间数据描述的是这个执行器，不是 实体 arm64 机器。
• 通用硬件驱动是携带的，不是合格的：上面列的 AHCI、NVMe、USB、网卡都没在实体 机器上跑过。
• 自动启动步骤只跑 amd64，所以这块板没有自动启动记录。
• 开发用的 Secure Boot 注册只存在于一次性的 AAVMF 变量里，不为别的平台的固件或调试 策略背书。

认证结果

绑定：QEMU aarch64 virt，-cpu max，virtio-blk，实验室固定的 AAVMF Secure Boot 固件，以及一份新组装的三分区镜像；没有实体机器。

归属：Mica OS 项目拥有该移植及其认证。没有厂商、没有 BSP 供应方，也没有在案的集成商。

模拟器的行是关于被模拟平台的证据，从不算作实机通过。

行	结果	日期	证据 / 原因
出厂布局与根的组成	pass	2026-09-09	QEMU virt 实验室运行
签名启动、运行时与干净关机	pass	2026-09-09	QEMU virt 实验室运行：认证的 root 与 support、身份、服务检查
完整 API 套件	pass	2026-09-09	QEMU virt 实验室运行
仅 root、仅 kernel 与组合更新	pass	2026-09-09	QEMU virt 实验室运行：三次健康试验失败后取用保留的回退，固件与身份不变
元数据拒绝与尝试耗尽	pass	2026-09-09	QEMU virt 实验室运行
网络 API	pass	2026-09-09	QEMU virt 实验室运行
安装与首次启动	not tested	—	没有实体机器
冷启动与热启动	not tested	—	没有实体机器
更新中断电	N/A	—	模拟存储；进程中断是另一类证据
射频与现场总线	N/A	—	这块板没有声明
物理恢复动作	N/A	—	没有物理在场断言

status: board-dependent — evidence: mica-build:boards/uefi-arm64/evidence.json, mica-build:tests/suites/lifecycle-uefi/updates.sh, mica-build:README.md