• 嵌入式
• 构建工具
• 操作系统

本篇文章聚焦 Armbian Build Framework 中patch/u-boot/u-boot-nanopi3-2016.01/这一"有意留空"的补丁目录，剖析其背后针对 Nexell S5P6818 平台的一整套引导加载器工程决策：为什么 known-good 的 rafaello7 2016.01 fork 不需要任何 Armbian 补丁、为什么启动镜像（NSIH + BL1 + u-boot.bin）以预构建 blob 形式由家族配置的uboot_custom_postprocess()组装，以及这一机制与write_uboot_platform()、启动脚本、内核侧 mainline bring-up 之间的完整调用链。读完本文，你将掌握在 Armbian 构建框架中"不编译 u-boot、改用已验证二进制"这一策略的落地细节，以及 S5P6818 平台从镜像写入到内核启动的完整链路。

补丁目录为什么是空的：一条有意的工程决策

patch/u-boot/u-boot-nanopi3-2016.01/README.md是理解整个 S5P6818 引导策略的入口。它用极简的文字说明了一个反直觉的事实：这个补丁目录被有意留空（Intentionally empty），全文要点如下：

• 该目录服务于 rafaello7 的 nanopi3 2016.01 fork（S5P6818 平台）；
• 这个 fork（由config/sources/families/s5p6818.conf中的BOOTSOURCE指定，tag 为v1.2）是known-good 引导加载器，不需要任何 Armbian 补丁；
• 启动镜像（NSIH + BL1 + u-boot.bin）由家族配置文件中的uboot_custom_postprocess()函数组装。

也就是说，BOOTPATCHDIR='u-boot-nanopi3-2016.01'在构建流水线中被正确指向（见 s5p6818.conf），但目录里刻意不放任何.patch文件。这是 Armbian 构建框架中一个典型的"补丁目录为空"的合法形态：补丁机制服务于"修正上游代码"，而当上游二进制本身被证明可用、且无法从源码重建时，最稳妥的做法就是不干预、直接复用。

S5P6818 与目标板卡：哪些设备走这条链路

S5P6818 是 Nexell 的八核 arm64 SoC，由两个 Cortex-A53 四核簇通过 CCI-400 相干互连组成。在 Armbian 中，使用这套启动策略的板卡全部集中在config/boards/下，共享BOARDFAMILY="s5p6818"：

从源码结构看，三块板的差异被刻意收敛为两点：DRAM 初始化（决定 1 GiB / 2 GiB blob）与设备树裁剪（决定全量树 / 最小树）。Fire3 使用最小设备树，是为了避免在全量树下游走不存在的外设而产生 phantom-probe 报错。u-boot 会在运行时把真实内存大小回填进设备树，因此 blob 只需按 1 GiB / 2 GiB 区分，无需逐板定制。

家族配置：BOOTSOURCE、BOOTBRANCH 与 no-op 构建目标

config/sources/families/s5p6818.conf 是这套策略的枢纽，它同时声明了"从哪里取 u-boot 源码"和"如何组装最终镜像"：

BOOTSOURCE='https://github.com/rafaello7/u-boot-nanopi-m3.git' BOOTBRANCH='tag:v1.2' BOOTDIR='u-boot-nanopi-m3' BOOTPATCHDIR='u-boot-nanopi3-2016.01' BOOTCONFIG='nanopim3_defconfig' BOOTSCRIPT='boot-s5p6818.cmd:boot.cmd' BOOTENV_FILE='s5p6818.txt' UBOOT_TARGET_MAP="ubootversion;;boot.img bootemmc.img" ATF_COMPILE="no"

几个关键点：

• BOOTSOURCE/BOOTBRANCH：源码仍会被拉取，但目的不是编译，而是"让 u-boot 产物流程有一个可对照版本的源码树"——构建框架可以据此记录版本、校验配置。
• BOOTPATCHDIR：指向本文主角u-boot-nanopi3-2016.01，目录为空，即不应用任何补丁。
• UBOOT_TARGET_MAP="ubootversion;;boot.img bootemmc.img"：分号前是 make 目标，这里用的是ubootversion——一个不产生任何产物的 no-op 目标；分号后是期望产物列表boot.img bootemmc.img，实际由后处理函数生成，而非编译生成。
• ATF_COMPILE="no"：该平台不经过 ATF 编译环节，S5P6818 的启动链由 ROM/2ndboot → BL1 → u-boot 组成，与依赖 ATF 的常规 arm64 流程不同。

注释还给出了两条"为什么必须这样做"的硬性理由（s5p6818.conf）：mainline v2026.07 移植冷启动复位循环；2016.01 fork 在现代主机上无法从源码构建。这两点将在下一节展开。

为什么不能从源码构建：两条被验证的死路

mainline v2026.07 移植：冷启动复位循环

仓库内保留了 patch/u-boot/v2026.07-s5p6818/ 这一"进行中"的 mainline 移植（0001-nexell-add-arm64-S5P6818-SoC-support.patch、0002-nexell-add-s5p6818_nanopim3-board-...patch），其状态标记为INCOMPLETE / WORK IN PROGRESS：

• 暖重启：可以正常启动；
• 冷启动（上电）：复位循环，崩溃发生在早期 C 代码（board_init_f/arch_cpu_init），早于控制台初始化，并沿 nexell 的clk_init/cpu_soc_init级联；
• 由于mach-nexell代码与 2016.01 fork 等价（而 fork 可以冷启动），排查结论指向2026 u-boot 框架与 GCC-15 早期环境的细微差异（未初始化的冷启动内存 / 重定位 / early-heap 顺序），而非 SoC 支持本身；盲目的串口探测式二分已耗尽，需要 JTAG 读取故障 PC/EC、或改走 from-SPL 构建才能破解。

2016.01 fork：现代主机上的 libfdt 冲突

即使回到 known-good 的 2016.01 fork，它在现代构建主机上也无法从源码编译：其 host 工具（通过lib/libfdt的fdtgrep/mkimage）会与系统安装的libfdt-dev发生符号/头文件冲突，导致构建失败。

手工组装同样失败

s5p6818.conf 注释明确记录：无论是手工拼装的 BL1+NSIH+u-boot.bin，还是 rafaello7 v1.2 的预构建产物，都与真正能启动的二进制存在差异，板子无法启动。换言之，该平台存在"能用的二进制"与"能从源码得到的二进制"不重合的现象，唯一被证明有效的产物，就是从一台工作状态良好的板载安装中逐字节捕获的 blob。

预构建 blob：uboot_custom_postprocess() 如何组装启动镜像

blob 的来源与内容

packages/blobs/nanopi/ 下存放了四个文件：1g-bl1-nanopi.bin、2g-bl1-nanopi.bin，以及两份完整启动镜像boot-nanopi3-1g.img、boot-nanopi3-2g.img。后者的内容为BL1 + NSIH + u-boot "2016.01-armbian"，是从 known-good 板载安装中"原样捕获"（byte-identical）的，即实际能冷启动+暖启动于 EL2 的那份引导加载器。

1 GiB / 2 GiB 的选择逻辑

s5p6818.conf 中的uboot_custom_postprocess()是组装的核心。板卡间唯一的差异是DRAM 初始化，它位于 BL1 内部，因此存在 1 GiB 与 2 GiB 两个版本，由$BOARD决定：

uboot_custom_postprocess() { # 2 GiB blob 捕获自 NanoPC-T3+ 的 eMMC；1 GiB 来自最后一个 # known-good 的 Armbian Fire3 镜像（21.02.1） if [[ $BOARD == nanopct3plus ]]; then cp "$SRC/packages/blobs/nanopi/boot-nanopi3-2g.img" boot.img else cp "$SRC/packages/blobs/nanopi/boot-nanopi3-1g.img" boot.img fi ... }

两份 blob 携带同一个 "2016.01-armbian" u-boot，仅 BL1 内的 DRAM 初始化不同；NanoPi M3 / Fire3 / NanoPC-T3 都走 1 GiB 分支，只有 2 GiB 的 NanoPC-T3+ 走 2 GiB 分支。

偏移 0x50：SD / eMMC 启动选择字节

紧随其后的代码操作 blob 中偏移 0x50（80）处的一个字节，它决定 ROM/2ndboot 使用哪个启动设备：0 = SD，2 = eMMC：

# 捕获的 blob 来自 eMMC（=2）；强制 boot.img 为 SD、 # bootemmc.img 为 eMMC，使各介质无需按 BOOT 键即可自动启动 printf '\0' | dd of=boot.img bs=1 seek=80 conv=notrunc status=none cp boot.img bootemmc.img printf '\2' | dd of=bootemmc.img bs=1 seek=80 conv=notrunc status=none }

这一小段逻辑把同一份二进制派生出两个变体：boot.img（SD 选择字节）与bootemmc.img（eMMC 选择字节），从而让用户插 SD 或刷 eMMC 都能免按键自启动。

与编译流水线的衔接

uboot_custom_postprocess并非框架的特殊例外，而是标准后处理钩子。lib/functions/compilation/uboot.sh 中，编译完成且savedefconfig之后，框架会检测该函数是否存在并调用它：

if [[ $(type -t uboot_custom_postprocess) == function ]]; then display_alert "${uboot_prefix}Postprocessing u-boot" "${version} ${target_make}" uboot_custom_postprocess fi

S5P6818 的情况特殊在：常规流程中该钩子处理的是"编译出的" u-boot 二进制，而这里它处理的是从 blob 复制来的成品。此外，uboot_custom_postprocess与write_uboot_platform的函数体还被计入产物哈希（artifact-uboot.sh），这意味着任何改动都会正确触发产物缓存失效。

write_uboot_platform()：把镜像写到 sector 1

后处理负责"组装镜像"，而把镜像落到目标介质则由 s5p6818.conf 中的write_uboot_platform()完成：

write_uboot_platform() { # 只有板载 eMMC 才写入 eMMC 选择字节的 bootemmc.img（选择字节 = 2）。 # 此 SoC 的设备树别名把 SD 映射为 mmc0（/dev/mmcblk0）、eMMC 映射为 # mmc2（/dev/mmcblk2）；镜像创建面向 loop 设备。因此 eMMC 是 # bootemmc.img 的唯一目标——其余介质（SD 卡、镜像 loop 设备） # 一律写入 SD 选择字节的 boot.img。 if [[ "$2" == /dev/mmcblk2 ]]; then dd if=$1/bootemmc.img of=$2 seek=1 status=noxfer > /dev/null 2>&1 else dd if=$1/boot.img of=$2 seek=1 status=noxfer > /dev/null 2>&1 fi }

两个值得注意的工程细节：

1. seek=1（sector 1）：镜像从第 1 个扇区写入，而 BL1 本身位于 blob 内的 sector 0。这正是"分区表保留第一个扇区、启动链从 sector 1 起读"的经典布局，也解释了后处理中为什么说"blob 已自带 sector 0 的 BL1"。
2. eMMC 判定：判断条件基于设备路径/dev/mmcblk2，而不是通用规则——因为此 SoC 的设备树别名把 SD 映射到 mmc0、eMMC 映射到 mmc2。镜像生成时目标通常是 loop 设备，因此除真正的 eMMC 之外，一切介质（含 SD 与镜像 loop 设备）都写入 SD 选择字节的boot.img。

该函数在镜像构建时由 lib/functions/image/loop.sh 调用（write_uboot_platform "${TEMP_DIR}${DIR}" "$loop"），并在用户侧nand-sata-install等场景被复用——也就是说，同一份函数既负责"造镜像时预写"，也负责"用户刷机时写入"。

启动脚本 boot-s5p6818.cmd：与 blob 配套的运行期流程

引导加载器就位后，真正把内核拉起来的脚本是 config/bootscripts/boot-s5p6818.cmd，它与 blob 是一套经过验证的组合，其中几处硬编码负载了本平台的特殊性：

加载地址布局与 2 MiB 对齐

# Load map（2 GiB DRAM 起始 0x40000000）。arm64 Image 基址必须 2 MiB 对齐 # （booti 要求）；0x41000000 满足该要求，且不同于旧的 0x4a000000， # 为大型（edge）内核留出空间，避免与 ramdisk 重叠。 setenv kernel_addr_r "0x41000000" setenv fdt_addr "0x48000000" setenv ramdisk_addr_r "0x49000000"

这段注释记录了一次真实故障的修复：旧地址kernel@0x4a000000会覆盖大于 16 MiB 的uInitrd@0x49000000，导致坏 CRC；新的0x41000000同时满足booti的 2 MiB 对齐要求并消除重叠风险。

console 与 earlycon 处理

脚本读取/boot/armbianEnv.txt（或 s5p6818.txt 中的默认verbosity=7、console=both），支持display/serial/both三种 console 组合。earlycon=s5pv210,mmio32,0xc00a1000是无条件注入的：该 SoC 的 arch-timer/console 交接需要早期串口可见，否则直到ttySAC0探测前控制台都是静默的，板子会在 "Starting kernel" 处看起来像死机。

nr_cpus=4：CCI-400 一致性问题

这是整个启动参数中最关键的坑（boot-s5p6818.cmd）：

setenv bootargs "earlycon=... ${consoleargs} root=${rootdev} rootwait ... nr_cpus=4 ${extraargs}"

S5P6818 是八核 SoC，由两个 Cortex-A53 四核簇通过 CCI-400 相干互连连接。2016 fork 的 u-boot（即 blob 内那份）通过 PSCI CPU_ON 把 cluster1 带上线，却从未为该簇启用互连的 snoop/DVM，导致 cluster1 的缓存与 cluster0 非相干运行。在多核负载下这会静默破坏内存——manifest 为段错误、malloc/tcache 中止、栈溢出、SIGILL，且已被证明与负载相关、与频率无关，并非热/电源/DRAM 问题。将 Linux 限制在 cluster0（4 核）后完全稳定（压力测试 0 失败，对比全 8 核约 10% 失败率）。注释明确写道：一旦 blob 的 PSCI 修复了 cluster1 的 CCI 一致性，即可移除nr_cpus=4，恢复全部 8 核。

加载与启动

脚本依次ext4load设备树（优先armbianEnv.txt指定的fdtfile，回退到 M3 全量树）、uInitrd与Image，最后booti启动；并在文件末尾保留mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr的重编译提示。

内核侧佐证：mainline nexell 平台 bring-up

启动链之外，内核侧也体现了同一套"以 known-good 为锚、渐进推进"的思路。patch/kernel/archive/s5p6818-7.2/ 包含两组补丁：0001-arm64-nexell-minimal-S5P6818-platform-bring-up-conso...patch（新增arch/arm64/boot/dts/nexell/下的s5p6818.dtsi与s5p6818-nanopi-m3.dts，最小化串口/平台 bring-up）与0002-arm64-nexell-S5P6818-boot-enablement-timer-udelay-EL...patch（timer、udelay、专用的nexell,s5p6818-uartsamsung_tty drvdata）。注释说明 mainline 从未携带该 SoC（验证至 7.2 均缺席），整套 nexell 平台（Kconfig、clk、pinctrl、serial、timer、dw_mmc 胶水、GbE/USB/I2C/RTC/PWM/thermal 与设备树）由这些补丁从 rafaello7 4.14 BSP 移植而来并在硬件上验证。因此该家族当前仅有edge分支（7.2 非 LTS，尚无可用的 current/LTS 目标）。

遗留工作与后续路线

家族配置的 TODO 注释与 v2026.07 移植的 README 共同勾勒出后续路线：

1. 从源码构建：待 host-tools/libfdt 冲突（2016.01 fork）或 v2026.07 冷启动崩溃修复后，恢复真正的源码编译；
2. 修复 PSCI / CCI 一致性：让 blob 内 u-boot 的 PSCI 为 cluster1 启用 CCI coherency，从而移除nr_cpus=4限制、恢复 8 核；
3. 捕获 1 GiB 版 BL1 的完整记录：1 GiB blob 来自最后的 known-good Armbian Fire3 镜像（21.02.1），而 2 GiB blob 捕获自 NanoPC-T3+ eMMC，两者来源均已注明，便于日后审计与复现。

这一系列安排最终形成了一个闭环：目录留空 = 不干预已验证的二进制；预构建 blob = 唯一被证明能启动的产物；后处理/写入/启动脚本 = 把它正确部署到各介质并拉起内核。对任何接手 S5P6818 平台维护的开发者而言，patch/u-boot/u-boot-nanopi3-2016.01/README.md、s5p6818.conf 与 boot-s5p6818.cmd 三份文件共同构成了最完整的平台档案。

• 嵌入式
• 构建工具
• 操作系统