分区布局、启动流程、U-Boot、设备树、内核细节 分析日期：2026-05-22

本篇下钻到硬件和引导层：eMMC/NVMe 分区表、U-Boot 启动链、内核编译细节和设备树。结论先行：升级模型是 Recovery + Staging，不是 A/B；系统用了 Android 的引导链，但上层是标准 Debian + systemd。

一、分区布局完整解析

eMMC 分区表（GPT）

NVMe SSD 分区表（GPT）

分区命名规律

PARTLABEL 遵循 Android 命名惯例（uboot/misc/boot/recovery/oem/userdata），但这不是 Android 系统——init 是 systemd，没有任何 Android framework。

分区 GUID 有明显规律：

f2690000-0000-4c72-8000-62e0000025d6  → uboot
ba240000-0000-4410-8000-56090000642c  → misc
28300000-0000-4a6d-8000-1ffa00000b93  → boot
...

GUID 的最后一个 group 包含 62e00000、56090000、1ffa0000 等——看起来像某种 checksum 或 hash 前缀，不是标准 GUID，说明是用自研工具生成的 GPT 分区表。

二、升级模型：Recovery + Staging，不是 A/B

不是 A/B 双分区

真正的 A/B 升级需要两套完整分区（boot_a + boot_b、rootfs_a + rootfs_b）。极空间的分区表没有这种对称结构。

实际方案：Recovery + Source 暂存区

当前运行状态：
  boot (p3) ← 当前内核
  rootfs (p6) ← 当前系统

升级流程：
  1. 下载新内核镜像 → source_kernel (p10)
  2. 下载新 rootfs 镜像 → source_rootfs (p11)
  3. 备份当前内核到 backup (p5)
  4. 设置 misc 分区标记 → 下次启动进入 recovery 模式
  5. 重启

Recovery 模式：
  recovery (p4) 内核启动
  → 将 source_kernel → boot (p3)
  → 将 source_rootfs → rootfs (p6)
  → 清除 misc 标记
  → 重启

回滚（如果新系统启动失败）：
  watchdog 检测 → 自动从 boot 分区当前内核回退
  或手动从 backup (p5) 恢复

证据

1. 内核 cmdline：androidboot.mode=normal — 支持多种启动模式（normal/recovery/charger 等），借鉴 Android bootloader 协议
2. misc 分区：4MB，用于存储 U-Boot 和 recovery 之间的通信（类似 Android BCB — Bootloader Control Block），当前为空说明系统正常运行
3. recovery/backup/source_ 分区全为空*：说明被分析设备尚未执行过系统升级（当前的 ZOS V1.2.0200068 是出厂预装或初始烧录的）
4. 内核配置支持：CONFIG_ROCKCHIP_EFUSE=y 用于安全启动和防回滚，CONFIG_ROCKCHIP_SIP=y 用于与 TrustZone 通信

三、U-Boot 启动流程

U-Boot 分区格式

uboot 分区（p1）头部魔数：0xd00dfeed

这不是标准的 Rockchip U-Boot 格式。标准 Rockchip loader 格式通常以 RKNS 或 LOADER 为魔数。d00d feed（“dude feed”）可能是：

• 自定义的 loader 头部格式
• 或者是 Rockchip 的某个变体格式（某些 RK SDK 版本使用 0xD00DFEED 作为 TPL/SPL 的头部）

文件结构（4MB = 4096KB）：

0x00000 - 0x00E00  : TPL/SPL (Trusted/Secondary Program Loader)
0x00E00 - 0x00B50  : ATF (ARM Trusted Firmware) 或其他固件
0x00B50 - 0x7FAE   : U-Boot proper
bafe 9000          : entry point ≈ 0x90000000 (U-Boot 典型加载地址)

启动链（推断）

BootROM (Rockchip 片内)
  → mmcblk0boot0/boot1 (eMMC boot partition, 4MB each)
    → TPL (mmcblk0p1, 少量代码)
      → SPL (mmcblk0p1, DDR 初始化)
        → ATF (ARM Trusted Firmware, EL3)
          → U-Boot proper (mmcblk0p1)
            → 读取 misc 分区, 决定启动模式
            → 加载 kernel from boot (p3)
            → 加载 DTB (内嵌或独立)
            → bootm → Linux

关键：GRUB 是假的

/boot/grub/grub.cfg 里有 Debian Live 系统的残留配置（linaro-alip 用户名），这不是实际使用的引导器。实际引导由 U-Boot 直接加载内核，GRUB 文件是 Debian 基础系统打包时留下的残留物，从未被使用。

四、内核详情

编译信息

内核模块（仅加载了 5 个）

Module     Size      Used by   用途
fusb302    28KB      0         USB Type-C PD 控制器
xt_geoip   16KB      0         GeoIP 防火墙规则匹配
ifb        16KB      0         网络流量整形
bcmdhd     1544KB    0         Broadcom WiFi 驱动
zfuse      135KB     2         ZFUSE 内核组件

极简内核——与标准 Linux 发行版加载几十个模块形成鲜明对比。嵌入式系统的典型做法：不用的功能不编译进内核也不作为模块。

ZFUSE 是内核模块

CONFIG_ZFUSE=m            # 编译为可加载内核模块
CONFIG_FUSE_FS=y          # 标准 FUSE 编译进内核

zfuse 有 135KB 的内核模块（不是纯用户态 FUSE），被 2 个内核组件引用。这证实 zfuse 用于在 /data_n001/data/udata/real 上实现项目配额管理。第 1 篇《系统架构总览》中"FUSE 用户态文件系统"的描述以本篇为准。

关键内核配置

CONFIG_ARCH_ROCKCHIP=y          # Rockchip 平台
CONFIG_ROCKCHIP_EFUSE=y         # eFuse 安全启动/防回滚
CONFIG_ROCKCHIP_SIP=y           # TrustZone 安全通信
CONFIG_PCIE_ROCKCHIP=y          # PCIe（NVMe SSD 走 PCIe）
CONFIG_PCIE_ROCKCHIP_HOST=y     # PCIe Root Complex 模式
CONFIG_DWMAC_ROCKCHIP=y         # 千兆以太网
CONFIG_WL_ROCKCHIP=y            # Rockchip WiFi 框架
CONFIG_ROCKCHIP_REMOTECTL=y     # 红外遥控
CONFIG_SPI_ROCKCHIP_SFC=y       # SPI Flash 控制器
CONFIG_PINCTRL_ROCKCHIP=y       # 引脚控制

模块签名

CONFIG_MODULE_SIG 未启用——模块加载没有签名验证，这对 NAS 消费设备来说安全性偏弱。

五、设备树 (Device Tree) 分析

基础信息

compatible: rockchip,rk3568-evb1-ddr4-v10
            rockchip,rk3568
model:      Rockchip RK3568
内存:       2MB-130MB(128MB) + 148MB-3840MB(3692MB) ≈ 3.7GB
内核 cmdline: androidboot.mode=normal

基于 Rockchip 官方的 EVB (Evaluation Board) DDR4 参考设计，不是从头设计的硬件。

内存映射

保留区域：
  drm-logo         : 0xEDF00000-0xEE000000 (约1MB)    - GPU 启动 Logo
  drm-cubic-lut    : 0xEFF00000-0xEFF08000 (32KB)    - 3D LUT 色彩表
  ramoops          : 0x00110000-0x00200000 (960KB)    - 内核崩溃日志

CPU

4× Cortex-A55 (cpu@0, cpu@100, cpu@200, cpu@300)
频率档位: 408/600/816/1104/1416/1608/1800/1992 MHz
当前调速器: ondemand
当前频率: 1992 MHz (满载)

GPU

型号: Mali-G52 1 core r1p0 (0x7402)
内核驱动: mali (ARM Mali 官方驱动)
中断: 3 个 (JOB/MMU/GPU)
电源域: 独立电源域
工作频率: 通过 OPP 表管理

Mali-G52 是 ARM 的中端 GPU，1 核心配置是 RK3568 的标准规格。支持 OpenGL ES 3.2、Vulkan 1.1、OpenCL 2.0。

NPU

驱动版本: RKNPU v0.8.2
频率档位: 200/300/400/600/700/800/900/1000 MHz
供电: rknpu-supply（独立电源轨）
IOMMU: 支持

RK3568 的 NPU 算力约 0.8 TOPS (INT8)，用于 AI 相册的人脸识别、场景分类、物体检测。独立电源轨说明可以在空闲时完全断电以省电。

显示子系统

vop@fe040000 (Video Output Processor)
  - VP0: 主显示输出
  - VP1: 副显示输出

接口：
  hdmi@fe0a0000        - HDMI 2.0 输出
  edp@fe0c0000          - eDP 嵌入式 DisplayPort
  dsi@fe060000/fe070000 - MIPI DSI (双通道)
  ebc@fdec0000          - EBC (E-Ink 电子墨水屏控制器！)

EBC (eBook Controller) 的存在非常意外——这意味着 RK3568 硬件支持电子墨水屏，但 T2 没有用到。这可能是芯片本身支持的能力，设备树中保留而已。

存储接口

sdhci@fe310000    - eMMC 控制器
dwmmc@fe2b0000    - SD 卡
dwmmc@fe2c0000    - SDIO (WiFi)
sata@fc000000     - SATA ×3 端口 (RK3568 原生，T2 未使用)
pcie@fe260000     - PCIe 2.0 ×1 (NVMe 0)
pcie@fe270000     - PCIe 2.0 ×1 (NVMe 1)
pcie@fe280000     - PCIe 2.0 ×1 (未使用, 可用于 WiFi 或扩展)

RK3568 有 3 个 SATA 端口，T2 完全没有使用——这是因为它用 NVMe SSD 替代了传统的 SATA 硬盘。

其他硬件外设

can@fe570000/fe580000        - CAN 总线 ×2 (工业/车载接口, T2 未用)
ethernet@fe010000/fe2a0000   - 千兆以太网 ×2 (T2 只用了一个)
usb@fd800000/fd840000        - USB 3.0 OTG + Host ×2
usb@fd880000/fd8c0000        - USB 2.0 Host ×2
fusb302                      - USB Type-C PD 控制器
rkisp@fdff0000               - ISP 图像信号处理器 (支持摄像头)
rkcif@fdfe0000               - CIF 摄像头接口
csi2-dphy0/1/2               - MIPI CSI 摄像头接口 ×3
saradc@fe720000              - SAR ADC (按键/LED 背光?)
rk808/rk817                  - 电源管理 IC
watchdog@fe600000            - 硬件看门狗
tsadc@fe710000               - 温度传感器

CAN 总线、3 个 MIPI CSI 摄像头、ISP 图像处理器——RK3568 的硬件能力远超 T2 的实际需求，极空间选择这款 SoC 可能是基于性价比和供货考虑。

六、与 Android 的关系

用到的 Android 引导协议

内核 cmdline:
  androidboot.storagemedia=emmc    - Android 引导参数
  androidboot.mode=normal          - 启动模式（normal/recovery）

分区命名:
  uboot / misc / boot / recovery / oem / userdata
  （完全遵循 Android 分区命名规范）

misc 分区:
  充当 Android BCB (Bootloader Control Block)
  用于 normal ↔ recovery 模式切换

没有用到的 Android 部分

✗ 没有 init.rc（init 是 systemd）
✗ 没有 adbd
✗ 没有 servicemanager / hwservicemanager
✗ 没有 Android framework (Zygote/ART)
✗ 没有 vold（存储管理用自研的 storagepool）
✗ 没有 healthd
✗ 没有 /system/build.prop
✗ 没有 selinux（CONFIG_SECURITY_SELINUX 可能未启用）

结论：极空间用了 Android 的引导链（BootROM→U-Boot→misc 分区协议）和分区命名，但上层完全是标准 Linux（Debian + systemd）。这是常见做法——用 Android 的 BSP 引导链（因为 Rockchip 提供的就是 Android BSP），然后替换 rootfs 为自己的系统。

七、关键发现总结

1. 不是 A/B 升级，是 Recovery + Source Staging 模式。source_kernel 和 source_rootfs 两个暂存分区在被分析设备上为空，说明尚未执行过系统升级
2. U-Boot 魔数 0xd00dfeed 非标准 Rockchip 格式，可能是自定义 loader 头部
3. zfuse 不是纯 FUSE，有 135KB 内核模块，用于存储配额管理
4. GRUB 是假象——/boot/grub/ 里的文件是 Debian 基础系统残留，实际引导由 U-Boot 直接完成
5. GPU Mali-G52 1核、NPU 0.8 TOPS、3×SATA 未使用、CAN 总线存在——RK3568 的硬件能力被大量裁剪
6. 内核模块极简：只加载了 5 个模块（fusb302/xt_geoip/ifb/bcmdhd/zfuse）
7. 模块签名未启用：安全策略偏弱
8. 基于 Rockchip EVB 参考设计 (evb1-ddr4-v10)，不是完全自研的硬件设计