配置 Avaota A1 的 Linux 设备树
原理图上能看到 eMMC、串口、网口和供电芯片，Linux 源码里却没有这些器件的照片。内核收到的是一棵设备树：SoC 公共文件描述 T527 有哪些控制器，Avaota A1 板级文件再说明哪些控制器接了真实器件、使用哪组引脚和电源。
Linux 7.2 已经带有 Avaota A1 DTS，所以这里不是从空文件抄写整块板，而是沿着 include 关系确认主线已经描述了什么，再为 eMMC 增加当前启动验证需要的限制。status = "okay" 只是允许驱动尝试匹配；时钟、电源、复位或引脚有一项不对，probe 仍然会失败。
确认 T527 公共设备树
进入 mainline-a1，查看板级文件的包含关系：
sed -n '1,55p' \
linux-v7.2/arch/arm64/boot/dts/allwinner/sun55i-t527-avaota-a1.dts
板级 DTS 引用 sun55i-a523.dtsi，再通过 &uart0、&mmc2、&gmac0 等标签启用实际连接。两层职责如下：
| 文件 | 描述范围 |
|---|---|
sun55i-a523.dtsi | SoC 内部控制器地址、中断、时钟和 DMA |
sun55i-t527-avaota-a1.dts | 板载器件、电源、引脚和控制器启用状态 |
SoC DTSI 可以被多块板复用，因为控制器寄存器地址和中断号由芯片决定；板级 DTS 不能照搬，因为 eMMC 电源、复位脚、总线宽度和外接 PHY 由原理图决定。移植另一块 T527 板时，应复用 SoC 节点，再从原理图重建板级连接，而不是复制 Avaota A1 的整个 &mmc2。
根据原理图检查串口和 eMMC
sed -n '/chosen {/,/};/p' \
linux-v7.2/arch/arm64/boot/dts/allwinner/sun55i-t527-avaota-a1.dts
sed -n '/&mmc2 {/,/};/p' \
linux-v7.2/arch/arm64/boot/dts/allwinner/sun55i-t527-avaota-a1.dts
Linux 7.2 上游 DTS 已提供 UART0 控制台、8 位 eMMC、1.8 V I/O 电源、DDR/HS200 能力和不可移除属性。当前工程为了与 U-Boot 的保守读取路径一致，暂时删除 DDR/HS200 能力，改为 4-bit、25 MHz，并明确这条总线不承载 SD/SDIO 设备。
打开 arch/arm64/boot/dts/allwinner/sun55i-t527-avaota-a1.dts，在 &mmc2 中加入：
&mmc2 {
bus-width = <4>;
cap-mmc-hw-reset;
no-sd;
no-sdio;
max-frequency = <25000000>;
non-removable;
/* 其余电源和 pinctrl 属性保持主线原值。 */
};
no-sd 与 no-sdio 避免在焊接 eMMC 的总线上探测其他卡类型；max-frequency 与 SPL 阶段的 25 MHz 保守上限一致。它不是永久关闭 HS200 的性能结论，提升频率前需要完成 MMC2 采样延时实测。
这些属性分成“硬件事实”和“当前调试限制”两类：
- 上游的
bus-width = <8>来自板级连线，但当前调试配置主动降为 4-bit，用于绕开尚未标定的 8-bit 采样窗口； no-sd、no-sdio把该总线限定为 eMMC；- 删除
mmc-ddr-1_8v与mmc-hs200-1_8v，防止 Linux 在当前阶段重新协商到尚未验证的高速模式； max-frequency = <25000000>给 Linux MMC 核心设置当前上限，临时压住未校准的高速采样问题。
如果 25 MHz 仍出现 CRC 错误，应回到供电、pinctrl、总线宽度和采样延时，而不是继续添加协议能力属性。若低速稳定，再逐级提高频率并保存误码与冷启动结果。
反编译 DTB 检查最终配置
make -C buildroot-2026.05.1 -j"$(nproc)" linux-rebuild
dtb=buildroot-2026.05.1/output/images/sun55i-t527-avaota-a1.dtb
test -s "$dtb"
dtc -I dtb -O dts "$dtb" \
| sed -n '/mmc@4022000 {/,/};/p'
反编译结果中应出现 bus-width = <4>、no-sd、no-sdio 和 max-frequency = <0x17d7840>，并且不再出现 mmc-ddr-1_8v、mmc-hs200-1_8v；十六进制 0x17d7840 即 25,000,000 Hz。检查生成的 DTB 才能证明修改进入了 Buildroot 输出。
反编译 DTB 的意义是检查 C 预处理、DTS include 和 dtc 合并后的最终结果。源码里出现一个属性，但被后续节点覆盖、文件未进入当前构建或 Buildroot 仍使用旧 DTB 时，只有生成物能暴露差异。上板后还要结合 /proc/device-tree 和驱动 probe 日志，才能证明内核实际使用了这份 DTB。
本次成功日志仍打印 new high speed DDR MMC card，说明板上固件没有使用当前这份“4-bit、25 MHz、无 DDR/HS200”Linux DTB。它能验证 U-Boot 修复与 Linux 启动链，却不能作为当前 Linux DTS 修改已经生效的证据；重新生成 raw 时必须再次核对 DTB。
U-Boot 和 Linux 各自拥有一份 Avaota A1 DTS。修改 Linux 文件不会自动改变 SPL 或 U-Boot 阶段的 MMC 时钟，两处必须分别验证。
这也是判断修改位置的关键：FIT 尚未读出时，Linux DTS 还不存在于执行路径；Linux 启动后 eMMC 才报错时，再检查 Linux DTS 和 MMC 驱动。根据串口停止阶段选择源码层，比在两份 DTS 中同步试错更可靠。