1. 项目概述从SPL到U-Boot的启动探秘最近在折腾君正Ingenic T32平台也就是大家常说的Zeratul方案的U-Boot移植和优化特别是对启动流程的分析这几乎是所有嵌入式Linux开发者绕不开的“必修课”。网上关于君正平台尤其是T32这类较新芯片的启动分析资料要么是零零散散的代码片段要么是语焉不详的旧文档真正能把从芯片上电到U-Boot命令行出现的完整链条讲清楚的少之又少。我自己在调试“快启”需求时就曾在这个环节卡了很久反复对照数据手册和源码才理清头绪。今天我就把自己对君正Zeratul平台U-Boot启动流程的完整分析、关键代码跟读心得以及那些数据手册上没写的“潜规则”整理出来希望能帮到同样在摸索的你。简单来说君正T32这类MIPS架构的芯片其启动过程并非U-Boot“一蹴而就”。它遵循一个典型的多阶段引导模型芯片内部的BootROM我们无法修改首先运行然后加载并运行SPLSecondary Program Loader相当于U-Boot的小型化前身最后由SPL来加载并跳转到完整的、功能丰富的U-Boot主程序。这个过程环环相扣任何一个环节的镜像格式、加载地址或初始化步骤出错都会导致系统“趴窝”。理解它不仅是移植的基石更是后期进行启动加速、安全引导等深度优化的前提。2. 启动流程全景与阶段划分要分析启动流程我们得先建立起一个全局视角。君正T32的启动链可以清晰地划分为三个物理上隔离的阶段每个阶段都有其明确的职责和生命周期。2.1 第一阶段芯片固件BootROM这是芯片出厂时就固化在硅片内部的微代码用户无法修改。它的任务非常单纯且关键初始化最基础的硬件例如配置芯片从上电的默认时钟源切换到稳定的内部振荡器初始化用于启动的存储控制器如SPI NOR Flash控制器到最基本的工作状态。从启动介质加载SPL根据芯片的启动引脚Boot Pin配置决定从哪个外部存储器如SPI NOR Flash、NAND Flash、SD卡的固定位置通常是起始地址读取一小段代码。对于T32常见的是从SPI NOR Flash的0x00000000地址开始读取。验证与跳转BootROM会校验加载到内部SRAM的这段代码的头部信息如君正自定义的“帧头”校验通过后便将CPU的控制权交给这段代码也就是SPL。注意BootROM对加载的SPL镜像有严格的格式要求并非一个纯粹的二进制文件。它要求SPL镜像前必须包含一个特定的数据结构帧头其中包含了镜像长度、加载地址、入口地址等关键信息。如果镜像格式不对BootROM会直接判定启动失败。2.2 第二阶段SPLSecondary Program LoaderSPL可以理解为“U-Boot的精简版”。因为BootROM只能将代码加载到芯片内部容量有限的SRAM中T32可能为64KB或128KB在这公小的空间里不可能放下功能完整的U-Boot。因此SPL的核心使命就是“铺路搭桥”为加载“大个头”的U-Boot主程序准备环境。它的核心工作包括初始化关键DRAM控制器这是SPL最核心的任务。芯片内部的SRAM很小U-Boot主程序通常几百KB和Linux内核根本放不下。SPL必须正确配置外部DDR SDRAM的时序参数使其能够正常工作。这部分代码通常直接来自君正提供的SDK参数与具体的板载DDR芯片型号强相关。初始化更丰富的存储设备在DRAM可用后SPL可以初始化更复杂的存储设备如eMMC、SD卡、NAND Flash等以便从这些设备中读取更大的U-Boot主程序镜像。加载U-Boot主程序从指定的存储设备如eMMC的某个分区中将U-Boot主程序镜像加载到DRAM中预先约定好的地址如0x80800000。跳转到U-Boot最后SPL通过一个函数指针跳转将CPU控制权彻底移交给位于DRAM中的U-Boot主程序入口点。2.3 第三阶段U-Boot主程序当U-Boot主程序开始执行时它已经“住”在了宽敞的DRAM里。此时它可以大展拳脚完整的硬件初始化初始化串口用于调试输出、网卡、USB、GPIO等所有板级外设。环境变量管理从Flash上的环境变量分区加载bootargs、bootcmd等配置。引导操作系统执行bootcmd命令通常是加载Linux内核镜像uImage或fitImage、设备树dtb到内存并跳转到内核执行。整个流程就像一场接力赛BootROM第一棒固定选手→ SPL第二棒轻装速跑选手→ U-Boot主程序第三棒全能选手→ Linux内核终点线。我们的分析和定制工作主要聚焦在SPL和U-Boot主程序这两棒。3. 代码跟读从_start到board_init_f理论清楚了我们直接深入代码。以君正SDK中常见的U-Boot代码为例我们从汇编入口开始看看程序到底是怎么跑起来的。3.1 SPL的入口与重定位SPL的入口点在汇编文件arch/mips/cpu/start.S中标签_start处。这是CPU从BootROM跳转过来后执行的第一条指令所在地。.globl _start _start: /* 1. 设置异常向量基地址 */ la t0, except_vec3_generic mtc0 t0, CP0_EBASE /* 2. 设置栈指针(sp) */ li sp, CONFIG_SPL_STACK_BASE addiu sp, sp, -CONFIG_SPL_STACK_SIZE /* 3. 清零BSS段 */ la t0, __bss_start la t1, __bss_end bss_clear_loop: sw zero, 0(t0) addiu t0, t0, 4 blt t0, t1, bss_clear_loop /* 4. 调用C语言入口函数 */ jal spl_board_init这段汇编做了几件关键事设置异常向量告诉CPU发生异常时如中断去哪里找处理程序。建立栈空间C语言函数调用需要栈。CONFIG_SPL_STACK_BASE通常指向内部SRAM的末端栈向下生长。这是SPL能调用C函数的基础。清理BSS段BSS段存放未初始化的全局变量和静态变量需要在上电后清零。__bss_start和__bss_end由链接脚本定义。跳转到C代码最终调用spl_board_init()这是一个弱符号定义的函数通常定义在板级文件board/ingenic/t32/中用于完成非常早期的、与具体电路板相关的初始化例如配置启动LED指示灯、检测启动模式拨码开关等。实操心得在调试极早期启动问题时如果串口还没有初始化无法打印日志我通常会利用一个GPIO指示灯。在spl_board_init里将其设置为输出并在不同代码位置翻转电平。用示波器或直接观察LED的闪烁 pattern就能判断代码执行到了哪个阶段这是排查“黑屏”问题的土法炼钢利器。随后执行流会进入common/spl/spl.c中的spl_common_init()和spl_board_prepare_for_linux()等函数但SPL阶段的核心是board_init_f()。3.2 关键函数board_init_f解析board_init_f是U-Boot初始化框架中一个至关重要的函数它在SPL和U-Boot主程序阶段都会被调用但行为完全不同。理解它的双重身份是理清启动流程的关键。在SPL阶段它的主要任务是初始化DRAM并重定位自身。代码位于arch/mips/lib/spl.c或板级相关文件中。void board_init_f(ulong dummy) { /* 1. 初始化全局数据指针gd */ gd (gd_t *)CONFIG_SPL_GD_BASE; /* 2. 最基础的板级初始化 */ board_early_init_f(); /* 3. 初始化串口 */ serial_init(); /* 4. 打印启动横幅 */ puts(\nU-Boot SPL PLAIN_VERSION \n); /* 5. 核心初始化DRAM控制器 */ dram_init(); /* 6. 将SPL自身代码从SRAM复制到DRAM重定位*/ spl_relocate_stack_gd(); /* 7. 后续初始化... */ board_init_r(); }为什么需要重定位因为内部SRAM空间紧张。当dram_init()执行成功后DRAM就可以用了。此时为了给后续操作如从Flash读取U-Boot主程序腾出更多的SRAM空间作为缓冲区也为了统一后续代码的运行环境SPL会把自己从SRAM拷贝到DRAM的高端地址区域。这个过程就是“重定位”。重定位后栈、全局数据(gd)等地址都会相应更新。dram_init()函数详解 这个函数是板级相关的通常位于board/ingenic/t32/t32.c。它的内容直接来自君正SDK的DDR初始化代码。int dram_init(void) { /* 通常直接调用君正SDK提供的DDR初始化函数 */ sdram_init(); /* 将检测到的DRAM大小赋值给gd-ram_size */ gd-ram_size get_ram_size((void *)CONFIG_SYS_SDRAM_BASE, CONFIG_SYS_MAX_RAM_SIZE); return 0; }sdram_init()这个函数内部会按照你板子上DDR芯片的型号例如DDR3L 4Gb精确地配置DDR控制器的几十个时序参数如tRCD、tRP、tRAS、tRFC等。这些参数值通常保存在一个独立的头文件或C文件中例如ddr_params_t32_xxx_mhz.c。踩坑记录这里是最容易出问题的地方。如果DDR参数配置有误轻则系统不稳定重则根本无法启动。君正SDK通常会提供针对某款参考设计板的参数文件。如果你的板子更换了DDR颗粒品牌或型号绝不能直接套用。必须根据新颗粒的数据手册重新计算并调整这些参数。我曾经因为用了不同封装的同型号颗粒ODT片上终端电阻配置没改导致大批量生产时出现随机启动失败教训深刻。3.3 SPL如何加载U-Boot主程序DRAM就绪后SPL便进入加载U-Boot主程序的阶段。这个逻辑在board_init_r()函数及其后续调用中。关键函数是spl_load_image()。SPL支持从多种设备加载这取决于CONFIG_SPL_XXX_LOAD如CONFIG_SPL_MMC_LOAD、CONFIG_SPL_NAND_LOAD的配置。以从eMMC加载为例/* 例如在 spl_mmc.c 中 */ boot_device spl_boot_device(); // 确定启动设备如MMC switch (boot_device) { case BOOT_DEVICE_MMC1: case BOOT_DEVICE_MMC2: err spl_mmc_load_image(); // 从MMC加载镜像 break; // ... 其他设备 } /* 在 spl_mmc_load_image 内部 */ /* 1. 读取存储设备上的U-Boot主程序镜像到DRAM缓冲区 */ mmc_init(); // 初始化MMC控制器 block_dev mmc_get_blk_desc(mmc); mmc_bread(block_dev, uboot_partition, image_size_sectors, load_buffer); /* 2. 解析镜像头部可能是Legacy uImage或FIT格式*/ switch (genimg_get_format(load_buffer)) { case IMAGE_FORMAT_LEGACY: header (struct legacy_img_hdr *)load_buffer; /* 校验CRC、获取入口地址等 */ entry_point image_get_ep(header); break; case IMAGE_FORMAT_FIT: /* 解析更复杂的FIT镜像 */ break; } /* 3. 跳转到U-Boot主程序 */ typedef void __noreturn (*image_entry_noargs_t)(void); image_entry_noargs_t entry (image_entry_noargs_t)entry_point; entry(); // 跳转关键点加载地址CONFIG_SYS_LOAD_ADDR或CONFIG_SYS_TEXT_BASE定义了U-Boot主程序在DRAM中的加载地址。这个地址必须与U-Boot主程序在编译链接时指定的链接地址TEXT_BASE完全一致。通常这个地址会选在DRAM开始地址之后的一个偏移处如0x80800000以避免与SPL自身、栈空间等冲突。4. U-Boot主程序的初始化流程当CPU跳转到U-Boot主程序的入口点后又是一套类似的启动流程但更加复杂和完整。主程序的入口同样在start.S但链接地址不同它一开始就运行在DRAM中。4.1 主程序的board_init_f与重定位主程序的board_init_f函数通常位于arch/mips/lib/board.c任务与SPL不同初始化一系列前置驱动如串口用于更丰富的输出、定时器、GPIO等。规划内存布局计算并确定U-Boot自身、堆heap、栈stack、设备树fdt、内核映像等最终在内存中的位置。这是一个复杂的“拼图”过程。执行全局重定位这是U-Boot一个经典且重要的概念。U-Boot编译时假设自己运行在链接地址如0x80800000但SPL可能把它加载到了另一个临时地址虽然我们通常让两者一致。board_init_f阶段会计算出一个“重定位偏移”并将U-Boot的代码段、数据段等全部拷贝到最终规划好的内存位置并更新所有全局指针和函数指针。跳转到重定位后的board_init_r。这个重定位过程对于实现U-Boot的“位置无关”运行至关重要也是支持bootm命令加载内核到任意地址的基础。4.2 主初始化序列board_init_rboard_init_r函数在common/board_r.c是U-Boot主初始化的核心。它通过一个初始化序列表init_sequence_r依次调用几十个初始化函数顺序极其重要init_fnc_t init_sequence_r[] { initr_trace, // 跟踪调试 initr_reloc, // 重定位完成标志 initr_caches, // 启用数据/指令缓存 initr_reloc_global_data, board_init, // **板级后期初始化**非常重要 initr_serial, // 串口重新初始化 initr_announce, initr_malloc, // 初始化堆管理器 initr_nand, // 初始化NAND Flash initr_mmc, // 初始化MMC/SD initr_env, // 初始化环境变量 initr_net, // 初始化网络 // ... 更多 run_main_loop, // 进入主循环等待命令 };board_init()函数详解 这是开发者最需要关注的板级初始化函数位于board/ingenic/t32/t32.c。在这里你需要完成所有在SPL阶段没做或做不全的硬件初始化。int board_init(void) { /* 1. 配置地址总线 */ ingenic_address_bus_init(); /* 2. 初始化GPIO设置默认状态 */ gpio_request(CONFIG_STATUS_LED_GPIO, status_led); gpio_direction_output(CONFIG_STATUS_LED_GPIO, 1); /* 3. 初始化I2C总线用于连接PMIC、EEPROM等 */ i2c_init_all(); /* 4. 初始化以太网PHY芯片 */ if (board_phy_config(phydev) 0) { printf(Ethernet PHY init failed!\n); } /* 5. 初始化USB控制器 */ usb_init(); /* 6. 读取板卡信息如从EEPROM */ board_read_id(); return 0; }注意事项board_init()中的初始化顺序有讲究。通常应先初始化总线如I2C再初始化挂在该总线上的设备如PMIC。网络PHY的复位引脚可能由GPIO控制因此GPIO的初始化要在网络之前。仔细规划顺序可以避免一些隐晦的驱动问题。4.3 环境变量与bootcmd当initr_env()被调用时U-Boot会尝试从预设的存储介质如eMMC的某个分区、SPI Flash的某个偏移加载环境变量。如果加载失败第一次启动则使用编译时嵌入的默认环境。环境变量bootcmd定义了自动启动的命令序列。一个典型的君正T32的bootcmd可能如下# 在 include/configs/t32_common.h 中定义的默认值 #define CONFIG_BOOTCOMMAND \ mmc dev 0; \ # 选择eMMC设备0 ext4load mmc 0:2 0x81000000 fitImage; \ # 从eMMC第2分区加载FIT镜像到内存 bootm 0x81000000 # 从该地址启动内核bootm命令会解析fitImage一种包含内核、设备树、可能还有ramdisk的打包格式将其各个组件解压到正确的内存地址最后跳转到内核入口。5. 调试技巧与常见问题排查分析启动流程离不开调试。这里分享几个在君正平台上非常实用的调试方法和常见问题。5.1 串口调试与早期打印串口是嵌入式调试的生命线。确保CONFIG_BAUDRATE和板卡实际硬件匹配。在board_early_init_f或spl_board_init中就需要尽早初始化串口引脚复用Pinctrl。有时为了更早打印甚至在board_init_f之前会用汇编代码配置一个最简串口。如何判断代码死在哪个阶段完全无输出连SPL的“U-Boot SPL”横幅都没有。问题很可能在BootROM加载SPL阶段。检查SPL镜像格式是否使用了正确的工具如mkimage或君正专用工具为SPL添加了帧头烧录地址SPL是否烧写到了启动介质的正确起始位置如SPI Flash的0x0DDR参数如果SPL横幅出现后死机大概率是dram_init()中的DDR参数错误。可以尝试用示波器测量DDR的时钟和复位信号或者用点灯法定位死机代码行。SPL有输出但U-Boot主程序无输出SPL执行完毕但跳转到主程序后卡住。检查加载地址与链接地址确认SPL加载U-Boot主程序的地址CONFIG_SYS_LOAD_ADDR和U-Boot编译时的链接地址TEXT_BASE是否完全相同。镜像完整性通过工具校验U-Boot主程序镜像在存储介质上的CRC是否正确。可能是烧写过程出错。重定位冲突检查U-Boot主程序规划的内存布局是否与硬件或其他组件如共享内存区冲突。5.2 利用JTAG进行深度调试当串口信息不足以定位复杂问题时JTAG是终极武器。连接JTAG调试器如J-Link配合OpenOCD后你可以单步执行在_start处开始单步精确跟踪程序流。查看/修改内存和寄存器在dram_init()前后查看DDR控制器的寄存器配置与数据手册比对。设置断点在跳转到U-Boot主程序的entry()函数处设断点看是否成功跳转。一个典型的内存读写测试方法在U-Boot命令行或早期代码中# 在U-Boot命令行测试DRAM mtest 80800000 80801000 # 或者用循环写入特定pattern的代码如果测试失败表明DRAM初始化不稳定需要回调DDR参数。5.3 常见问题速查表现象可能原因排查方向上电后毫无反应串口无任何输出1. 电源或时钟故障2. BootROM未运行3. SPL镜像格式错误或烧录位置不对1. 测量核心电压、时钟频率2. 确认启动引脚配置3. 检查SPL是否带正确帧头并用编程器确认Flash内容打印出乱码串口波特率、数据位、停止位配置错误核对U-Boot配置与串口调试工具设置是否一致卡在“U-Boot SPL”或“DRAM:”之后DDR初始化失败1. 检查DDR芯片型号与参数文件是否匹配2. 用示波器看DDR复位、时钟、参考电压3. 简化参数降低频率测试SPL正常但提示“Loading U-Boot”后卡住U-Boot主程序加载失败1. 检查CONFIG_SYS_LOAD_ADDR2. 检查存储设备eMMC/SD初始化是否成功3. 校验U-Boot镜像CRCU-Boot启动后网卡、USB不识别相关外设驱动初始化失败或时钟未开启1. 检查board_init()中对应外设的初始化代码2. 检查设备树dts中该外设的节点状态是否为okay3. 检查内核时钟配置5.4 启动优化实践加快启动速度在理解了完整流程后优化启动速度就有了方向SPL阶段优化精简SPL功能通过CONFIG_SPL_XXX选项移除不需要的驱动如USB、网络减小镜像体积加快加载和执行速度。优化DDR初始化DDR训练Training耗时较长。对于固定硬件可以考虑使用已训练好的固定参数跳过训练过程如果芯片支持。君正SDK中可能有CONFIG_SKIP_LOWLEVEL_INIT相关选项。U-Boot主程序优化减少初始化设备通过环境变量或配置延迟初始化或不初始化当前启动不必要的外设如HDMI、音频。使用CONFIG_BOOTDELAY0取消启动延时直接执行bootcmd。内核压缩与格式使用lz4或lzo压缩方式的内核比gzip解压更快。使用fitImage打包内核和设备树一次加载避免多次读取存储设备。启动流程的分析就像解一道精密的多层谜题每一层都依赖于前一层的正确完成。从BootROM的硬性规则到SPL的轻量级铺路再到U-Boot主程序的全面接管每一步都有其设计哲学和实现细节。掌握它不仅能解决眼前的启动问题更能为后续的性能调优、功能定制打下坚实的基础。希望这篇基于君正T32平台的分析能为你点亮嵌入式系统启动世界的一盏灯。