一、背景与现象

1.1 设备环境

1.2 触发条件

  1. 使用镜像写入工具（balenaEtcher / Rufus DD 模式等）将 FriendlyElec eflasher 格式的 Proxmox VE ARM64 镜像完整写入 32GB SD 卡；
  2. 将 SD 卡插入 NanoPi R5S 后重启，等待设备从 SD 卡引导安装器。

1.3 具体表现

  • 设备每次启动均直接进入 eMMC 上原有的 iStoreOS，eflasher 安装界面从未出现；
  • 反复重刷镜像、更换写入工具，现象不变；
  • SSH 登录原系统后发现，SD 卡上的分区被自动挂载为数据盘（/mnt/mmc0-9），说明 SD 卡本身识别与写入均正常。

1.4 影响范围

  • eflasher 安装流程完全无法启动，目标系统（Proxmox VE）无法写入；
  • 原有 eMMC 系统与 NVMe 数据不受影响；
  • SD 卡上的镜像数据完好，但无法发挥设计用途。

二、原因分析

2.1 根因：RK3568 BootROM 的启动优先级

Rockchip RK3568 的 BootROM 按以下顺序尝试引导，该顺序固化在 SoC 内部，软件无法调整：

text
SPI NOR Flash → eMMC → SD Card

关键点：

  • 该设备未焊接 SPI NOR Flash（/proc/mtd 为空），启动链中只剩 eMMC 与 SD 两级；
  • eMMC 上存在完整可引导系统（iStoreOS），BootROM 命中 eMMC 后不会再尝试 SD 卡；
  • 因此无论 SD 卡写入得多正确，引导阶段永远轮不到它。

需要注意，这一行为与 RK3399（NanoPi R4S）相反——RK3399 的 BootROM 默认 SD 卡优先。同为 FriendlyElec 产品线，两款机型的启动逻辑截然不同，是最容易凭经验误判的地方。

2.2 eflasher 方案的设计前提

eflasher 是 FriendlyElec 的"安装器套装"，不是可直接上传刷写的系统镜像。其 SD 卡结构如下：

eflasher.conf 关键配置：

ini
[General]
; 开机后自动安装的 OS 目录
autoStart=proxmox-arm64
; 安装前对目标盘做全盘擦除
disableLowFormatting=false
; 拔出 SD 卡后自动重启
autoRebootWhenSDBeEjected=true

eflasher 的工作流程依赖一个隐含前提：SD 卡必须能优先于 eMMC 启动（SD 引导 → 进入安装器 → 将载荷写入 eMMC）。在 RK3568 + eMMC 已有系统的组合下，该前提不成立，安装流程在第一步就被拦截。换言之，本次"刷机失败"并非镜像写入或制作工具的问题，而是引导优先级问题。

三、逐步排查流程

以下命令均通过 SSH 在路由器上以只读方式执行，未做任何破坏性变更。

步骤 1：确认设备可达

bash
ping -n 2 10.0.1.1

预期结果：设备应答，TTL=64，表示设备在线。

说明：先排除设备变砖的可能，确认可以远程诊断，而不必先拆机接串口。若此处不通，排查方向应转向硬件与串口救砖。

步骤 2：获取机型与系统信息

bash
ubus call system board

输出（节选）：

json
{
    "model": "FriendlyElec NanoPi R5S LTS",
    "release": {
        "distribution": "iStoreOS",
        "version": "24.10.5",
        "target": "rockchip/armv8"
    }
}

说明：target 为 rockchip/armv8 表明 SoC 属于 RK3568 系。SoC 型号决定 BootROM 的启动顺序，是后续所有推理的核心依据，因此诊断第一步必须锁定机型。

步骤 3：确认当前启动介质

bash
lsblk
mount | grep -E ' on / | on /overlay '

输出（节选）：

text
mmcblk2      179:32   0  28.9G  0 disk
├─mmcblk2p1  179:33   0    64M  0 part /boot
├─mmcblk2p2  179:34   0   256M  0 part /rom
├─mmcblk2p3  179:35   0     2G  0 part /overlay
...
mmcblk2boot0 179:64   0     4M  1 disk
mmcblk2boot1 179:96   0     4M  1 disk
text
/dev/mmcblk2p3 on /overlay type ext4 (rw,relatime)

说明：/rom（squashfs 只读根）与 /overlay 均位于 mmcblk2，说明当前系统从 mmcblk2 启动；mmcblk2boot0/boot1 是 eMMC 硬件 boot 分区，可作为识别 eMMC 的强特征。

步骤 4：确认 SD 卡的识别状态与设备号

bash
cat /sys/block/mmcblk0/device/type
cat /sys/block/mmcblk2/device/type
dmesg | grep -E 'mmc[0-2].*(new|card)'

输出：

text
SD
MMC
[    1.805811] mmc0: new high speed SDHC card at address 0001
[    1.871186] mmc2: new HS200 MMC card at address 0001

说明：SD 卡（mmcblk0）在开机阶段即被内核识别，结合其分区已被挂载为数据盘的事实，可以排除"写卡失败 / 读卡异常"的分支——结论是写卡成功，失败发生在更早的引导阶段。区分 mmcblk0 与 mmcblk2 的设备类型，也是后续定位写入目标的必要前提。

步骤 5：确认 SPI NOR 是否存在

bash
cat /proc/mtd

输出为空。

说明：/proc/mtd 列出系统中所有 MTD 设备（含 SPI NOR）。为空说明启动链中不存在 SPI 一级，BootROM 的实际尝试顺序简化为 eMMC → SD。结合步骤 3 中 eMMC 可引导且被命中的事实，即可断定 SD 卡永远不会被尝试。

步骤 6：核对 SD 卡上的镜像形态

bash
mkdir -p /tmp/sdp1
mount -o ro /dev/mmcblk0p1 /tmp/sdp1
cat /tmp/sdp1/eflasher.conf
ls -lh /tmp/sdp1/proxmox-arm64/
umount /tmp/sdp1

输出（节选）：

text
-rwxr-xr-x  325.6K idbloader.img
-rwxr-xr-x    4.0M uboot.img
-rwxr-xr-x    3.0G rootfs.img
-rwxr-xr-x     438 parameter.txt

说明：分段镜像 + eflasher.conf 的组合证实这是 eflasher 安装器方案。它既不能通过 iStoreOS 网页的"刷写固件"入口上传（该入口只接受 squashfs-combined 格式的系统镜像），也无法在 SD 卡无法启动的前提下工作。此步同时确认了镜像载荷完整（rootfs.img 3.0G 在位），进一步佐证问题不在镜像本身。

步骤 7：汇总结论

四、结论与处理建议

4.1 结论

SD 卡刷机"失败"的根因是 RK3568 BootROM 的启动优先级：eMMC 上存在可引导系统时，SD 卡不会被尝试引导。镜像写入、写卡工具、SD 卡本身均无问题；eflasher 方案因依赖 SD 优先启动而整体失效。

4.2 处理方案

方案 B 的关键命令（在原系统内执行）：

bash
# 清零 eMMC 前 16MiB：覆盖 idbloader / uboot / 分区表头，使 eMMC 不可引导
dd if=/dev/zero of=/dev/mmcblk2 bs=1M count=16 conv=fsync
sync
reboot

执行后的预期行为：

  1. BootROM 找不到 eMMC 引导，回落到 SD 卡；
  2. eflasher 的 Ubuntu 运行环境启动，按 autoStart 配置自动将 Proxmox VE 写入 eMMC（3.0G 载荷约需 5–15 分钟）；
  3. 安装完成后拔出 SD 卡（autoRebootWhenSDBeEjected=true 触发自动重启），设备从 eMMC 进入新系统。

4.3 风险与救砖

  • 擦除操作会使 eMMC 上原系统及其数据不可恢复，执行前应完成配置备份；
  • eflasher 仅写入 eMMC，不触碰 NVMe 等其他存储介质；
  • 若擦除后 SD 引导仍然失败，设备将无法启动，救砖路径为：按住 Mask 键进入 MaskRom 模式，使用 RKDevTool 清空或重刷 eMMC。

五、后续预防措施

  1. 更换系统前先查 BootROM 启动顺序。 Rockchip 不同 SoC 的行为差异极大（RK3399 为 SD 优先，RK3568 为 eMMC 优先），应查阅 SoC 技术手册或厂商 wiki，而非凭同类机型经验推断。
  2. 区分两种镜像分发形态。 squashfs-combined（系统镜像，可 dd 或在线刷写）与 eflasher（安装器，需 SD 优先启动）的能力边界不同，选错形态会在写卡环节白费功夫。
  3. 写卡后先验证再上机。 检查分区表是否完整落盘（读卡器挂载或上机后 lsblk），可显著缩短"工具问题"与"引导问题"两条排查分支的距离。
  4. 保留救砖通道。 使用 RK3568 设备前建议先了解 MaskRom 模式与 RKDevTool 的清空 / 重刷流程，破坏性操作之前确认退路存在。
  5. 破坏性操作前完成备份。 eMMC 擦除、dd 覆盖等操作不可逆，配置与数据应先导出至独立存储介质。