Skip to main content

检查 T527 与 Avaota A1 的主线支持

移植并不等于从零编写四套代码。了解系统的启动顺序和构建关系后，再确认每个主线项目已经支持到哪一层：已有部分从官方文件继续验证，缺失部分才进入后续适配。

四个组件的主线支持情况​

项目官方版本Avaota A1/T527 现状本课程要做什么
TF-Av2.15.0没有 sun55i_a523 平台引入开发平台代码并验证 BL31
U-Bootv2026.07已有 defconfig 和板级 DTS从官方配置起步，解决实际启动问题
Linuxv7.2已有 A523 DTSI 和 Avaota A1 DTS复用已有描述，补充并验证板级差异
Buildroot2026.05.1没有 Avaota A1 板级配置新建 defconfig、overlay 和镜像规则

这张表决定后面的学习顺序：TF-A 是第一个源码缺口；U-Boot 和 Linux 不从空文件开始；Buildroot 在启动固件可用后再建立整机配置。

准备四个官方版本​

项目版本资料源码下载
TF-A2.15.0 文档v2.15.0 源码包
U-Bootv2026.07 标签v2026.07 源码包
Linuxv7.2 标签linux-7.2.tar.xz
Buildroot2026.05.1 标签buildroot-2026.05.1.tar.xz

推荐使用 Git，因为后续需要反复查看提交、补丁和本地修改。

展开 Git 获取命令
mkdir mainline-a1
cd mainline-a1

git clone --depth 1 --branch v2.15.0 \
  https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git \
  trusted-firmware-a-v2.15.0

git clone --depth 1 --branch v2026.07 \
  https://source.denx.de/u-boot/u-boot.git \
  u-boot-v2026.07

git clone --depth 1 --branch v7.2 \
  https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git \
  linux-v7.2

git clone --depth 1 --branch 2026.05.1 \
  https://gitlab.com/buildroot.org/buildroot.git \
  buildroot-2026.05.1

检查工作区时应看到四个同级目录：

mainline-a1/
├── trusted-firmware-a-v2.15.0/
├── u-boot-v2026.07/
├── linux-v7.2/
└── buildroot-2026.05.1/

下面的搜索必须在未修改的官方版本上执行。否则搜索结果只能代表本地工程，不能说明上游原本支持什么。

检查 TF-A 平台支持​

TF-A 为 Linux 和 U-Boot 提供 EL3 固件与 PSCI。先列出 2.15.0 已收录的全志平台：

find trusted-firmware-a-v2.15.0/plat/allwinner \
  -mindepth 1 -maxdepth 1 -type d -printf '%f\n' | sort

官方目录只有：

sun50i_a64
sun50i_h6
sun50i_h616
sun50i_r329

没有 sun55i_a523，搜索 A523/T527 也没有结果：

grep -RInE 'sun55i|a523|t527' \
  trusted-firmware-a-v2.15.0/plat/allwinner

因此缺少的是 A523/T527 SoC 家族的平台实现，不是一个 Avaota A1 板级配置文件。后续需要补入 CPU 拓扑、内存映射和 PSCI 电源管理代码，才能生成 T527 使用的 bl31.bin。

检查 U-Boot 板级支持​

在 U-Boot 中搜索板名：

find u-boot-v2026.07/configs \
  -maxdepth 1 -iname '*avaota*' -print

find u-boot-v2026.07/dts/upstream/src/arm64/allwinner \
  -maxdepth 1 -iname '*avaota*' -print

官方版本已经包含两处板级入口：

u-boot-v2026.07/
├── configs/avaota-a1_defconfig
└── dts/upstream/src/arm64/allwinner/
    └── sun55i-t527-avaota-a1.dts

关键配置说明它已经选择 Avaota A1 设备树、A523/T527 公共 SoC 实现、SPL 和 eMMC：

配置含义
CONFIG_DEFAULT_DEVICE_TREE="allwinner/sun55i-t527-avaota-a1"使用 Avaota A1 板级 DTS
CONFIG_MACH_SUN55I_A523=y复用 A523/T527 SoC 公共实现
CONFIG_SPL=y生成片内 SRAM 中运行的第一阶段
CONFIG_MMC_SUNXI_SLOT_EXTRA=2启用额外 MMC 控制器
CONFIG_SUPPORT_EMMC_BOOT=y支持 eMMC 启动分区

结论不是“U-Boot 已经完全可用”，而是 不需要从零建立板级身份。是否能从 Avaota A1 的 eMMC 冷启动，仍要由镜像布局和串口日志验证。

检查 Linux 设备树支持​

Linux 的 SoC 公共描述与板级描述分成两个文件：

linux-v7.2/arch/arm64/boot/dts/allwinner/
├── sun55i-a523.dtsi
└── sun55i-t527-avaota-a1.dts
文件描述内容
sun55i-a523.dtsiCPU、GIC、时钟、MMC、USB 等 SoC 内部控制器
sun55i-t527-avaota-a1.dtsAvaota A1 的电源、存储、网口、串口和板载器件连接

板级文件已经给出明确身份和调试串口：

arch/arm64/boot/dts/allwinner/sun55i-t527-avaota-a1.dts
/ {
	model = "Avaota A1";
	compatible = "yuzukihd,avaota-a1", "allwinner,sun55i-t527";

	aliases {
		serial0 = &uart0;
	};

	chosen {
		stdout-path = "serial0:115200n8";
	};
};

这证明 Linux 7.2 已经收录 T527/Avaota A1 设备树，不能把后续工作描述成“新增整块板的 Linux 支持”。课程要做的是核对实际硬件、补充必要限制，并逐项验证驱动。

检查 Buildroot 板级配置​

find buildroot-2026.05.1/configs buildroot-2026.05.1/board \
  \( -iname '*avaota*' -o -iname '*t527*' \) -print

官方 Buildroot 2026.05.1 没有匹配结果。缺失的是整机集成入口：

buildroot-2026.05.1/
├── configs/avaota_a1_mainline_defconfig
└── board/avaota/a1-mainline/
    ├── linux.fragment
    ├── rootfs-overlay/
    ├── post-build.sh
    └── genimage.cfg

Buildroot 负责组织工具链、Linux、根文件系统和最终镜像，不负责补齐 TF-A 或 U-Boot 的 SoC 启动代码。

确定需要完成的移植工作​

TF-A       补入 A523/T527 平台代码，生成 BL31
   ↓
U-Boot     从官方 Avaota A1 配置开始，验证 SPL、FIT 与 eMMC
   ↓
Linux      复用官方设备树，补充并验证板级差异
   ↓
Buildroot  新建整机配置，组织 rootfs 与 eMMC 镜像

检查结果表明，指定 TF-A 版本缺少 T527 所需的平台实现。下一阶段先准备 BL31，再由 U-Boot 将它与 SPL、U-Boot proper 和设备树组合起来。

下一节：为 T527 准备 TF-A