企业官网建设流程全解析

1. 从按下电源键到看见登录提示符：RK3576 启动链路全景拆解

搞嵌入式 Linux 的人都有一个共同的执念：板子上电那一瞬间，到底发生了什么？尤其是拿到一块 RK3576 的开发板，接上串口，看着终端里一行行滚动的 log，从BootROM到U-Boot再到内核解压、挂载根文件系统，最后蹦出login:提示符——这个过程看起来行云流水，但中间任何一个环节卡住，你面对的都是一块“砖”。

RK3576 是瑞芯微这两年在边缘计算和工业控制领域推得比较猛的一颗 SoC，四核 A72 加四核 A53 的大小核架构，配上 6TOPS 的 NPU，定位介于 RK3568 和 RK3588 之间。很多人拿它跟 RK3588 做对比选型，但真到了调试启动流程这一步，两者的 BootROM 行为、SPL 加载地址、U-Boot 的 defconfig 差异其实不小，直接照搬 RK3588 的经验很容易踩坑。

这篇内容我打算把 RK3576 从上电到根文件系统挂载的完整链路拆开讲。不是那种抄一遍芯片手册的流水账，而是结合我在实际板子上抓串口 log、改 DDR 参数、调 U-Boot 环境变量、配 rootfs 挂载参数的真实过程，把每个阶段“为什么这么设计”“参数怎么算”“卡住了怎么查”讲清楚。适合正在 bring-up RK3576 板子的驱动工程师、做嵌入式 Linux 系统集成的朋友，以及想搞明白 ARM64 SoC 启动链路到底怎么回事的开发者。哪怕你之前只玩过树莓派或者 RK3399，看完也能顺着这条线把 RK3576 跑通。

整条链路的核心关键词就几个：BootROM、SPL、U-Boot、Linux 内核、根文件系统。它们之间的关系不是简单的串联，而是层层接力、每一棒都有自己的加载地址和校验机制。下面我按启动顺序，一个阶段一个阶段地拆。

2. 启动链路整体设计与阶段划分逻辑

2.1 为什么 ARM64 SoC 要分这么多阶段启动

很多人第一次看启动流程会疑惑：为什么不把 U-Boot 直接烧到 SPI Flash 里，上电就跑？非要搞个 BootROM 再搞个 SPL，层层跳转不嫌麻烦吗？

这个问题的答案藏在芯片的制造工艺和存储介质特性里。RK3576 内部的 BootROM 是一块固化在 SoC 里的只读存储，容量很小，通常只有几十 KB，它在芯片流片时就写死了，改不了。这块 ROM 的唯一使命就是：从外部存储介质（eMMC、SD 卡、SPI NOR/NAND）里读出一小段代码，放到内部 SRAM 里执行。注意，是 SRAM，不是 DDR。

为什么不能直接加载到 DDR？因为 DDR 是一块“需要被初始化才能用”的存储。DDR 颗粒的时序参数、电压、刷新周期，这些都得根据具体板子上焊的是哪家的 DDR 来配置。BootROM 不可能预知所有 DDR 型号，所以它只能先把一小段“负责初始化 DDR 的代码”加载到内部 SRAM 里跑起来，这段代码就是 SPL（Secondary Program Loader）。

SPL 跑起来之后，第一件事就是根据板级参数把 DDR 初始化好，然后把完整的 U-Boot 从存储介质搬到 DDR 里，跳过去执行。U-Boot 这时候才拥有大内存可用，可以加载内核镜像、设备树、ramdisk，最后启动 Linux。

所以这条链路的本质是：BootROM 解决“从哪读”，SPL 解决“内存怎么用”，U-Boot 解决“系统怎么起”。三个阶段各司其职，缺一不可。RK3576 相比老一代芯片，BootROM 支持的启动介质更多，SPL 的 DDR 初始化代码也更复杂，因为要兼容 LPDDR4、LPDDR4X、LPDDR5 等多种颗粒。

2.2 RK3576 启动阶段的地址映射与接力关系

要理解启动流程，必须先把地址空间搞清楚。RK3576 的启动阶段涉及几个关键地址区域，我整理成表格方便对照：

这张表里的地址不是随便写的，每一个都有讲究。比如 SPL 运行在内部 SRAM，RK3576 的 SRAM 总量有限，所以 SPL 的代码必须精简，不能带文件系统驱动、不能带网络协议栈，只能带最基础的存储读取和 DDR 初始化。U-Boot proper 搬到 DDR 后地址就宽松多了，可以放完整的驱动模型。

接力关系上，BootROM 读 SPL 时会校验头部信息（RK 系列用的是 IDB 格式），SPL 读 U-Boot 时会校验 FIT 镜像或者 raw 镜像的 magic，U-Boot 读内核时会校验 Image 的头部和设备树的 FDT magic。每一棒都有校验，任何一棒校验失败，启动就停在那里，串口会打印对应的错误码。这也是为什么调试启动问题时，串口 log 是第一手资料。

2.3 存储介质选择对启动流程的影响

RK3576 支持从多种介质启动，不同介质对应的 BootROM 行为和 SPL 加载方式不一样，这个差异在实际调试中非常关键。

eMMC 启动是最常见的方案。BootROM 会去读 eMMC 的 boot 分区（通常是 boot0 或 boot1），SPL 和 U-Boot 就烧在那里。eMMC 的优点是速度快、容量大，缺点是烧录需要专用工具，量产时一般用瑞芯微的烧录工具通过 USB 或者 SD 卡引导。

SD 卡启动是调试阶段最常用的。把 SPL 和 U-Boot 按特定偏移写到 SD 卡上，BootROM 检测到 SD 卡插入就优先从 SD 启动。这个方案的好处是改一版烧一版，不用动板载 eMMC，调试效率高。但要注意 SD 卡的偏移地址和 eMMC 不一样，RK3576 的 SD 卡启动偏移通常是 0x4000（16KB）开始放 SPL。

SPI NOR 启动适合小容量、高可靠场景。SPI NOR 容量小，通常只放 SPL 和 U-Boot，内核和根文件系统放到 eMMC 或者通过网络加载。这种方案在工业控制板上很常见，因为 SPI NOR 的可靠性比 eMMC 高，不容易出现坏块。

提示：RK3576 的启动介质优先级由 BootROM 内部的启动顺序决定，通常是 SD 卡优先于 eMMC。如果你板子上插了 SD 卡但想从 eMMC 启动，要么拔掉 SD 卡，要么改 BootROM 的启动顺序配置（通过 eFuse 或者启动引脚）。

3. BootROM 阶段：上电后的第一段代码到底干了什么

3.1 BootROM 的初始化动作与启动介质探测

板子上电，电源管理芯片（PMIC）把各路电压拉起来，RK3576 的复位逻辑释放，CPU 从固化在芯片内部的 BootROM 起始地址开始取指。这一刻，DDR 还没初始化，外部存储控制器还没配置，整个系统只有内部 SRAM 和最基本的时钟可用。

BootROM 干的第一件事是配置系统时钟。RK3576 的 BootROM 会把主时钟切到一个安全的低频（通常是 24MHz 晶振经过 PLL 倍频后的一个中间频率），保证后续操作有时钟可用。然后它会初始化启动介质控制器，比如如果检测到 SD 卡插入，就配置 SDMMC 控制器；如果检测到 eMMC，就配置 eMMC 控制器。

探测顺序是 BootROM 内部写死的，RK3576 的典型顺序是：先探测 SD 卡，再探测 eMMC，再探测 SPI NOR/NAND。探测的方式是尝试读取介质的前几个扇区，看能不能读到有效的 IDB 头部。IDB 是瑞芯微定义的一种启动镜像格式，头部包含 magic、版本、镜像大小、校验和等信息。BootROM 读到有效 IDB 后，就知道这个介质上有可启动的镜像。

这里有个细节值得注意：BootROM 读 IDB 时会校验 CRC，如果 CRC 不对，它会认为这个介质上的镜像损坏，继续探测下一个介质。所以如果你烧录的 SPL 镜像 CRC 算错了，BootROM 会直接跳过，表现为“插了 SD 卡但从 eMMC 启动了”或者“什么都不启动”。这种情况用串口看 log 通常能看到 BootROM 打印的介质探测信息。

3.2 IDB 镜像格式与 SPL 加载地址解析

IDB 格式是理解 RK 系列启动的关键。一个典型的 IDB 镜像结构如下：

struct idb_header { uint32_t magic; // 0x544F4F42 ("BOOT" 的某种变体) uint16_t version; // 版本号 uint16_t flags; // 标志位 uint32_t image_size; // 镜像总大小 uint32_t crc32; // 镜像数据的 CRC32 uint32_t load_addr; // 加载到 SRAM 的目标地址 uint32_t entry_point; // 入口地址 // ... 其他字段 };

BootROM 读到这个头部后，会把image_size大小的数据从存储介质读到load_addr指定的 SRAM 地址，然后跳转到entry_point执行。RK3576 的 SPL 加载地址通常在0x0FF00000附近，这个地址在内部 SRAM 范围内，具体值由芯片设计决定，不能随便改。

实际调试中，如果你自己编译 SPL 并打包成 IDB 镜像，需要用瑞芯微提供的打包工具（比如mkimage的 RK 定制版本或者boot_merger工具）来生成正确的头部。手动拼头部很容易把 CRC 算错，导致 BootROM 不认。我一般直接用 SDK 里的打包脚本，改改配置文件就行，不自己造轮子。

3.3 BootROM 阶段的常见卡死点与串口诊断

BootROM 阶段出问题，表现通常是串口没有任何输出，或者只打印了一两行就停了。这个阶段能打印的信息很少，因为 UART 驱动可能还没完全初始化，BootROM 只会在关键节点打印一些调试信息。

常见的卡死点有几个。第一是电源问题，PMIC 输出的某路电压不对，导致 DDR 或者存储控制器供电异常，BootROM 探测介质时读不到数据。这种情况用万用表量各路电压就能定位。第二是晶振不起振，RK3576 依赖 24MHz 晶振提供基准时钟，晶振坏了或者负载电容不对，BootROM 连时钟都没有，自然什么都不打印。第三是启动介质焊接不良，eMMC 或者 SD 卡座虚焊，BootROM 探测不到介质。

诊断方法上，我习惯先用示波器看晶振有没有起振，再看串口 TX 引脚上电瞬间有没有波形。如果晶振正常、串口无输出，大概率是 BootROM 根本没跑起来，重点查电源和复位。如果串口有输出但停在某一行，就根据那行 log 判断卡在哪个介质探测环节。

注意：RK3576 的 BootROM 日志默认可能不打印，需要在硬件上把某个调试引脚拉高，或者通过 eFuse 配置打开 BootROM 日志。具体引脚定义查芯片的 datasheet，不同封装可能不一样。

4. SPL 阶段：DDR 初始化与 U-Boot 加载的核心环节

4.1 SPL 的两大使命：DDR 初始化和加载 U-Boot

SPL 被 BootROM 加载到内部 SRAM 后开始执行，它面临的是一个“内存只有几百 KB、DDR 还不可用”的窘境。所以 SPL 的代码必须极度精简，它只干两件事：初始化 DDR，然后把 U-Boot 从存储介质搬到 DDR 里。

DDR 初始化是 SPL 里最复杂、最容易出问题的部分。RK3576 支持 LPDDR4、LPDDR4X、LPDDR5 等多种颗粒，不同颗粒的时序参数、电压、ODT 配置都不一样。SPL 里有一段 DDR 初始化代码，通常由瑞芯微提供的工具根据你的 DDR 型号生成，包含大量的寄存器配置。

这段代码的核心逻辑是：配置 DDR 控制器的时钟和电压，然后按照 JEDEC 标准走一遍 DDR 训练流程（包括写电平训练、读电平训练、写 DQ 训练等），最后确认 DDR 可以正常读写。训练过程中如果某个步骤失败，SPL 会打印错误码并停住。

U-Boot 加载这一步相对简单，SPL 根据编译时配置的存储介质类型（eMMC、SD、SPI），调用对应的驱动读取 U-Boot 镜像。RK3576 的 SPL 通常支持从 FAT 分区读取 U-Boot，也支持从 raw 偏移读取。读取地址和 U-Boot 的加载地址在编译时确定，一般在include/configs/rk3576_common.h或者 defconfig 里定义。

4.2 DDR 参数配置与训练失败的排查思路

DDR 训练失败是 bring-up 阶段最常见的坑。表现是串口打印类似DDR training failed或者ddr init fail的 log，然后卡住。这个问题可能出在硬件，也可能出在软件配置。

硬件方面，先查 DDR 供电电压是否正常。LPDDR4 的 VDD1 通常是 1.8V，VDD2 是 1.1V，VDDQ 是 1.1V 或 0.6V，具体看颗粒规格。电压不对，训练肯定过不了。再查 DDR 颗粒的焊接，尤其是 BGA 封装的颗粒，虚焊或者连锡会导致某几个 DQ 线不通，训练时读写数据对不上。

软件方面，重点查 DDR 参数配置。瑞芯微 SDK 里通常有一个 DDR 配置工具（比如ddrbin_tool），你输入 DDR 型号、容量、频率，它生成对应的参数文件。这个文件里的参数如果和实际硬件不匹配，训练就会失败。我遇到过一种情况：板子上焊的是 LPDDR4X，但配置工具里选成了 LPDDR4，两者的 VDDQ 电压不一样，训练时好时坏，最后改对型号才稳定。

排查技巧上，我一般先用瑞芯微提供的 DDR 测试工具（在 U-Boot 阶段有ddr test命令）跑一遍全地址读写测试，看有没有坏块或者不稳定区域。如果测试通过但系统跑起来偶尔死机，可能是 DDR 刷新周期或者温度补偿参数没配好，需要微调。

4.3 SPL 加载 U-Boot 的偏移与镜像格式

SPL 加载 U-Boot 时，偏移地址和镜像格式是两个关键参数。RK3576 的 eMMC 启动方案里，SPL 通常烧在 boot 分区的 0x0 偏移，U-Boot 烧在 0x4000 或者更高的偏移。SD 卡启动方案里，SPL 烧在 0x4000，U-Boot 烧在 0x8000 或者更高。这些偏移不是随便定的，要避开分区表和文件系统的元数据区域。

镜像格式上，U-Boot 可以是 raw 镜像，也可以是 FIT 镜像。raw 镜像就是编译出来的u-boot.bin直接烧，SPL 按固定偏移读固定大小。FIT 镜像则把 U-Boot、设备树、FPGA 固件等打包在一起，SPL 根据 FIT 头部的描述加载对应组件。RK3576 的 SDK 默认用 FIT 镜像，因为灵活，可以同时支持多种板级配置。

实际烧录时，我一般用rkdeveloptool或者upgrade_tool这类工具，它们会按照 SDK 里的分区表自动把 SPL、U-Boot、内核、rootfs 写到正确位置。手动用dd命令烧录的话，一定要确认偏移地址，写错了 BootROM 或者 SPL 读不到，启动就断了。

5. U-Boot 阶段：从引导加载器到内核启动的桥梁

5.1 U-Boot proper 的初始化流程与板级配置

U-Boot 被 SPL 搬到 DDR 后开始执行，这时候 DDR 已经可用，U-Boot 可以做很多 SPL 做不了的事：初始化网络、USB、显示、文件系统驱动，解析环境变量，执行启动脚本。

RK3576 的 U-Boot 初始化流程大致是：先做基础的 CPU 和时钟初始化，然后初始化串口（所以你才能看到 U-Boot 的 log），接着初始化存储设备（eMMC、SD、SPI），再初始化网络和 USB，最后进入命令行或者执行启动脚本。

板级配置是 U-Boot 阶段最需要关注的部分。RK3576 的 U-Boot 用 defconfig 来管理板级配置，比如rk3576_evb_defconfig对应官方评估板。你自己的板子如果硬件设计和评估板不一样（比如 DDR 容量不同、PMIC 型号不同、网口 PHY 不同），就需要改 defconfig 或者设备树。

设备树在 U-Boot 阶段也开始起作用。U-Boot 有自己的设备树（通常叫u-boot.dtb），描述 U-Boot 运行时的硬件。这个设备树和内核的设备树是分开的，但很多节点是共享的。调试时如果 U-Boot 认不到某个外设，先查 U-Boot 设备树里有没有对应的节点和驱动。

5.2 环境变量与启动脚本的配置要点

U-Boot 的环境变量是控制启动行为的核心。RK3576 的默认环境变量里，bootcmd定义了启动时自动执行的命令序列，bootargs定义了传给内核的启动参数。

一个典型的bootcmd可能是这样的：

bootcmd=mmc dev 0; ext4load mmc 0:1 0x02080000 Image; ext4load mmc 0:1 0x08300000 rk3576-evb.dtb; booti 0x02080000 - 0x08300000

这条命令的意思是：切换到 eMMC 设备 0，从第一个分区加载内核 Image 到 0x02080000，加载设备树到 0x08300000，然后用booti命令启动内核。地址不是随便写的，0x02080000 是 RK3576 内核加载的推荐地址，0x08300000 是设备树的推荐地址，这些在芯片手册里有说明。

bootargs里最关键的是root=参数，它告诉内核根文件系统在哪里。比如root=/dev/mmcblk0p2表示根文件系统在 eMMC 的第二个分区，root=/dev/nfs表示通过网络文件系统挂载。还有console=参数指定串口控制台，rw或ro指定根文件系统读写权限。

提示：改环境变量可以用setenv命令，改完记得saveenv保存到存储介质，否则重启就丢了。调试阶段我习惯把bootdelay设长一点，给自己留时间按回车进命令行。

5.3 内核镜像、设备树与 ramdisk 的加载策略

U-Boot 加载内核时，涉及三个主要组件：内核镜像（Image 或 Image.gz）、设备树（.dtb）、可选的 ramdisk（initrd 或 initramfs）。

内核镜像的格式上，ARM64 通常用Image（未压缩）或者Image.gz（gzip 压缩）。压缩镜像体积小，但启动时需要 U-Boot 解压，会多花一点时间。RK3576 的 SDK 默认用Image，因为 eMMC 读取速度快，没必要为了省空间牺牲启动时间。

设备树的选择上，如果你的板子有多个硬件版本，可以用 U-Boot 的fdtfile环境变量动态选择对应的 dtb。比如fdtfile=rk3576-myboard-v2.dtb，这样同一套 U-Boot 可以适配不同版本的板子。

ramdisk 在 RK3576 上通常不用，因为根文件系统直接放在 eMMC 或者 SD 卡上。但在调试阶段，用 initramfs 可以快速验证内核能不能起来，不用等根文件系统挂载。initramfs 是编译进内核的，U-Boot 不需要额外加载。

加载策略上，我一般把内核和设备树放在 eMMC 的第一个 FAT 分区，根文件系统放在第二个 ext4 分区。这样 U-Boot 用ext4load或者fatload加载内核，内核启动后用root=/dev/mmcblk0p2挂载根文件系统。分区布局清晰，调试时换内核只需要替换 FAT 分区里的文件。

6. Linux 内核与根文件系统挂载阶段

6.1 内核解压、设备树解析与驱动初始化

U-Boot 执行booti命令后，控制权交给内核。内核首先做的是自解压（如果是压缩镜像），然后解析设备树，初始化各个子系统。

内核启动 log 是调试的重要依据。从Starting kernel ...开始，内核会打印大量信息：CPU 信息、内存布局、设备树解析结果、驱动加载情况。如果内核卡在某一行，通常是对应的驱动初始化失败。

设备树解析阶段，内核会读取chosen节点里的bootargs，这是 U-Boot 传过来的启动参数。然后内核根据设备树里的memory节点确定可用内存范围，根据cpus节点初始化 CPU，根据soc节点下的各种外设节点加载驱动。

驱动初始化顺序上，内核先初始化核心子系统（时钟、中断、GPIO），再初始化存储、网络、显示等外设。如果某个驱动依赖的时钟或者电源没配好，驱动会 probe 失败，内核 log 里会有probe failed或者timeout的提示。

6.2 根文件系统挂载参数与常见挂载失败原因

根文件系统挂载是启动流程的最后一关。内核根据bootargs里的root=参数找到根文件系统设备，然后调用对应的文件系统驱动挂载。

常见的挂载失败原因有几个。第一是root=参数写错了，比如设备名不对（/dev/mmcblk0p2写成了/dev/mmcblk1p2），或者分区号不对。第二是文件系统类型不匹配，bootargs里没指定rootfstype，内核自动探测失败。第三是存储驱动没加载，比如 eMMC 驱动没起来，内核根本看不到/dev/mmcblk0。

排查方法上，如果内核 log 里出现VFS: Cannot open root device或者Kernel panic - not syncing: VFS: Unable to mount root fs，基本就是根文件系统挂载失败。这时候先确认root=参数，再确认存储驱动有没有加载，最后确认文件系统本身有没有损坏。

我遇到过一种情况：eMMC 分区表改了，但bootargs里的分区号没跟着改，内核去挂载一个不存在的分区，自然失败。这种问题用fdisk -l或者parted看一下分区表就能定位。

6.3 从内核启动到用户空间 init 的交接

根文件系统挂载成功后，内核会执行根文件系统里的 init 程序（通常是/sbin/init或者/init），控制权从内核态转到用户态。init 程序负责启动各种系统服务，最后拉起登录 shell，你就能看到login:提示符了。

这个交接过程中，如果 init 程序不存在或者没有执行权限，内核会 panic。如果 init 程序存在但启动脚本有问题，系统可能卡在某个服务启动阶段，串口 log 会停在对应的服务名上。

调试用户空间问题时，我一般先用一个最小的 initramfs 验证内核能不能进用户态，排除内核和驱动的问题。然后再换成完整的根文件系统，逐步排查是哪个服务或者脚本导致启动卡住。

7. 启动链路调试实战：常见问题速查与避坑经验

7.1 串口 log 分段解读与故障定位表

串口 log 是调试启动问题的第一手资料。我把 RK3576 启动过程中常见的 log 分段和对应的故障点整理成表格：

这张表我一般贴在工位上，遇到问题先对照 log 定位到阶段，再按排查方向逐个排除。效率比盲目试要高得多。

7.2 启动失败的典型场景与解决路径

场景一：上电无任何串口输出。这个最棘手，因为没有任何信息。先查电源，再查晶振，再查串口线序。RK3576 的调试串口通常是 UART2，波特率 1500000，线序是 TX、RX、GND。线序接错或者波特率不对，看到的都是乱码或者空白。

场景二：SPL 打印 DDR 训练失败。先确认 DDR 型号和配置工具里选的是否一致，再量 DDR 各路供电。如果供电正常、型号也对，可能是 DDR 颗粒本身有问题，换一块板子试试。

场景三：U-Boot 起来了但找不到内核。检查bootcmd里的加载地址和分区号，确认内核镜像确实烧到了对应位置。可以用 U-Boot 的ls mmc 0:1命令看一下分区里有什么文件。

场景四：内核起来了但根文件系统挂载失败。检查bootargs里的root=参数，确认分区号和文件系统类型。用rootfstype=ext4显式指定文件系统类型，避免自动探测失败。

7.3 提升启动调试效率的实操心得

调试启动流程，我总结了几个能显著提升效率的习惯。

第一，串口 log 一定要完整保存。用minicom或者picocom的日志功能，把每次启动的 log 存成文件，方便对比。改了一个参数之后，对比新旧 log 的差异，能快速定位变化点。

第二，改参数要一次只改一个。DDR 参数、环境变量、设备树，一次改多个，出了问题不知道是哪个导致的。我一般改一个、烧一次、看一次 log，确认没问题再改下一个。

第三，善用 U-Boot 的命令行。U-Boot 起来后按回车进命令行，可以手动执行mmc read、md、mw等命令，直接读写内存和存储，验证硬件是否正常。这比反复烧录整包镜像快得多。

第四，准备一个最小可启动系统。一个最简单的内核加 initramfs，能启动到 shell 就行。用它验证 CPU、DDR、串口是否正常，排除硬件问题后再上完整系统。

注意：RK3576 的启动调试涉及硬件和软件两个层面，遇到问题先判断是硬件还是软件。硬件问题用示波器、万用表查，软件问题用 log 和命令行查。两者混在一起查，效率会很低。

8. 启动流程的扩展与定制化思路

8.1 双系统启动与 A/B 分区方案

产品化阶段，双系统启动和 A/B 分区是常见需求。RK3576 的 U-Boot 支持通过环境变量控制启动哪个系统，比如定义bootslot=a或bootslot=b，bootcmd根据这个变量加载对应分区的内核和根文件系统。

A/B 分区的核心是升级时写入非当前运行的分区，升级完成后切换启动槽。这样即使升级失败，也能回滚到旧版本。实现上需要在 U-Boot 里加一段逻辑，读取某个标志位（存在 eMMC 的某个保留分区或者 RTC 寄存器里），决定启动哪个槽。

这个方案我在工业网关项目里用过，配合瑞芯微的 OTA 升级工具，可以实现远程升级和自动回滚。关键点是标志位的读写要可靠，掉电不能丢，所以一般存在 eMMC 的 boot 分区或者专门的 misc 分区里。

8.2 安全启动与镜像签名校验

安全启动是另一个常见的定制需求。RK3576 支持安全启动，BootROM 会校验 SPL 的签名，SPL 校验 U-Boot 的签名，U-Boot 校验内核的签名。整条链路每一棒都验签，防止固件被篡改。

启用安全启动需要在 eFuse 里烧录公钥哈希，然后所有镜像都要用对应的私钥签名。这个过程不可逆，eFuse 烧错了芯片就废了，所以量产前一定要在开发板上验证充分。

签名校验会增加启动时间，因为每级都要做非对称加密运算。对启动时间敏感的场景，可以只对关键镜像签名，比如只签 SPL 和 U-Boot，内核和根文件系统不签。但这样安全性会打折扣，具体怎么取舍看产品需求。

8.3 启动时间优化与快速启动实践

启动时间优化是产品化的另一个重点。RK3576 从冷启动到用户空间，优化前可能需要十几秒，优化后可以压到几秒以内。

优化的思路有几个。第一，精简 SPL 和 U-Boot，去掉不需要的驱动和功能，减少初始化时间。第二，内核裁剪，去掉用不到的外设驱动和文件系统，减小内核体积，加快加载和解压。第三，根文件系统用 initramfs 或者 squashfs，减少挂载时间。第四，并行初始化，把没有依赖关系的驱动和服务并行启动。

我实测下来，把 U-Boot 的启动延迟设为 0、内核裁剪到只保留必要驱动、根文件系统用 squashfs，冷启动时间可以从 12 秒压到 4 秒左右。再激进一点，用内核的fastboot模式或者跳过某些初始化步骤，还能更快，但可能影响功能完整性。

启动流程的定制化没有标准答案，关键是理解每个阶段在干什么，然后根据产品需求做取舍。RK3576 的 SDK 提供了比较完整的配置选项，改起来不算太难，但每一步改动都要验证，确保不会引入新的问题。