搞嵌入式的人早晚都得过U-Boot这一关。这玩意儿说简单也简单无非就是个引导程序把内核从存储介质里读出来、放到内存里、跳过去执行说复杂也复杂因为它要面对五花八门的CPU架构、千奇百怪的内存布局、还有各种你想都想不到的外设初始化顺序。我自己刚接触U-Boot那会儿对着_start汇编一脸懵后来跟着源码一行行啃下来才发现启动流程真的不难——难的是没人告诉你该看哪里、怎么串起来。这篇文章我打算换个思路不给你讲零散的知识点而是从arch/arm/lib/vectors.S里的_start汇编入口开始一步步跟在代码后面走把从CPU上电到U-Boot进入C语言世界这条线完整走一遍。讲清楚每一段汇编在干什么、为什么要这么干、跳转到C之前发生了什么、之后又是怎么一步步把整个U-Boot跑起来的。看完你会得到一个完整的“启动流程图”以后自己调试启动问题、移植U-Boot到新板子都会有个清晰的大局观。1. 先把坐标系建立起来U-Boot启动流程到底分几个阶段很多人学U-Boot启动流程容易懵根本原因是脑子里没有坐标系。你东看一眼向量表西看一眼board_init_f每个文件都认识但串不起来。我建议先建立整体框架U-Boot启动本质上是三个阶段。1.1 三大阶段汇编入口、C前期初始化、C主流程第一阶段是汇编阶段。CPU上电后执行的第一段代码通常从_start标签开始到跳进_main函数前的位置结束。这段代码的特点是只能用汇编写因为C环境还没准备好——栈指针不确定、BSS段没清零、SDRAM可能还没初始化、异常向量表要对齐。汇编阶段做的事情概括起来就四件建立异常向量表、切换CPU到SVC模式并关中断、设置临时栈、清零BSS段。第二阶段是C前期初始化严格来说它已经从汇编跳进了C但干的事还是“给C世界铺路”。入口是_main它调用board_init_f做一系列板级初始化串口、计时器、内存控制器、早期调试信息。这个阶段有个核心任务——计算并执行代码的重定位。U-Boot最初可能在NOR Flash或者ROM里运行干到一半要把自己拷贝到内存里再接着跑这个过程叫relocate。为什么需要重定位因为Flash访问慢、不能写而U-Boot运行期间要频繁改数据必须在RAM里跑。第三阶段是C主流程。重定位完成后代码跳到新的位置继续执行进入board_init_r这时候才算是“完整的C世界”设备树解析、完整外设驱动加载、环境变量读取、最终进入main_loop命令循环。你在命令行敲boot、tftp、printenv都是在这个阶段。我用个不太严谨但好记的类比汇编阶段是“找块平地先落下脚”C前期是“把帐篷扎好、物资清点完”C主流程是“正式开张营业”。1.2 ARM架构下U-Boot入口在哪以ARMv7为例定位源码路径不同架构入口不同但套路相通。以最常见的ARMv7为例U-Boot的入口点在arch/arm/lib/vectors.S里的_start标签。真正上电后第一个执行的是这个文件里的第一条指令。不过有个绕不开的环境依赖他刚上电时中断向量表必须位于0x00000000或0xFFFF0000附近。某些芯片内部有ROM上电自动从内部ROM把代码搬到SRAM再跳转有些芯片支持直接从NOR启动_start就被映射到地址0。具体路径我整理了一下方便你对照源码找arch/arm/lib/vectors.S_start入口、异常向量表定义arch/arm/cpu/armv7/start.Sreset函数真正的初始化代码arch/arm/lib/crt0.S_main函数连接汇编和C的桥梁common/board_f.cboard_init_f重定位前的初始化common/board_r.cboard_init_r重定位后的初始化common/main.cmain_loop命令行主循环这套结构在ARMv8上略有不同多了armv8/start.S、exception.S但“汇编入口→C前期→C主流程”这条主线是完全一致的。2. 从_start汇编入口开扒每一步都在做什么废话不多说直接用代码开讲。我以ARMv7的vectors.S开头这段代码几乎每个U-Boot版本都长得差不多。_start: b reset /* 复位向量直接跳去实际启动代码 */ ldr pc, _undefined_instruction ldr pc, _software_interrupt ldr pc, _prefetch_abort ldr pc, _data_abort ldr pc, _not_used ldr pc, _irq ldr pc, _fiq2.1 中断向量表为什么第一条必须是b reset而不是ldr pc_start一上来就是8条指令每条代表一个异常向量。第一条是b reset后面七条清一色ldr pc, 某地址。这里面有个细节值得说为什么第一条不用ldr pc而用b因为在ARM中b指令是相对跳转不论这个向量表被加载到哪个地址跳转目标都是相对当前PC偏移计算出来的而ldr pc, _undefined_instruction是从一个内存字中加载绝对地址。上电时如果这段代码所在位置和链接地址一致比如链接地址就是0两者没差别但如果U-Boot是XIP原地执行从Flash启动Flash可能被映射到0x20000000之类的地址第一条用b就能确保无论代码跑在哪个基地址都能正确跳到reset。而后续异常向量加载的是绝对地址这些地址在重定位时会被修正。这是启动代码极少数“差一个字就翻天”的地方。你自己写异常向量表时第一个入口要么用b要么用ldr pc, reset千万别用ldr pc, [pc, #offset]这种。这倒不是绝对不能用而是容易在处理地址重定位时把自己坑了。_undefined_instruction这些标号紧随其后是8个字长的数据存放各异常处理函数的绝对地址。这也点出了另一个知识点ARM的异常向量表每个向量占4字节一共32字节但后面通常紧跟_start的其它内容一些平台会做.balignl 16, 0xdeadbeef来对齐防止意外。2.2 reset函数CPU模式的切换和“清场”操作b reset之后执行流进入了arch/arm/cpu/armv7/start.S的reset。这个函数干的第一件事是把CPU拽进SVC模式并关掉中断。为什么要SVC模式因为U-Boot是裸机程序不希望被中断打扰而且需要最高特权级访问系统寄存器。代码通常是这样的reset: mrs r0, cpsr bic r0, r0, #0x1f /* 清掉模式位 */ orr r0, r0, #0xd3 /* 设为SVC模式关IRQ和FIQ */ msr cpsr, r0解释一下cpsr是ARM的程序状态寄存器低5位是处理器模式位。0xd3二进制是1101 00110x1f是0001 1111。bic把低5位清零orr填入0x13SVC模式同时第6、7位IRQ和FIQ禁止位置1就是关中断。这里有个经验之谈不要只在汇编里关一次中断。很多平台后面C代码初始化时还会通过cpsr或GIC通用中断控制器的操作再关一遍这是有道理的——汇编阶段只关了CPU核心的IRQ/FIQ但外设的中断信号可能已经挂在GIC上了到了timer_init、board_init_f阶段如果GIC没初始化中断一开就会出幺蛾子。所以U-Boot常见的做法是汇编关CPU中断C阶段初始化好GIC后再统一开中断。接着reset里会做一系列平台相关的初始化比如/* 关MMU和D-Cache */ mrc p15, 0, r0, c1, c0, 0 bic r0, r0, #0x1000 /* 清掉I-Cache位 */ bic r0, r0, #0x0004 /* 清掉D-Cache位 */ bic r0, r0, #0x0001 /* 清掉MMU位 */ mcr p15, 0, r0, c1, c0, 0为什么上来就关MMU因为上电后页表还没建立MMU开着只会让地址翻译乱套。D-Cache也得关否则你往内存写数据数据不知道是进了cache还是进了内存后面DDR初始化时地址会变得不可预期。I-Cache一般可以关也可以不关U-Boot有的版本会保留I-Cache加速但保守起见还是关掉。这段里面还经常包含cpu_init_cp15、cpu_init_crit这些子函数名字差不多实际就是操作CP15协处理器去初始化MMU、Cache、TLB不同SoC差异极大。2.3 预处理的那些“前置小动作”lowlevel_init与平台初始化在reset的尾巴上通常会有这样一个调用bl lowlevel_initlowlevel_init在大多数板子上是给DDR初始化做准备的。它的位置在arch/arm/mach-xxx/lowlevel_init.S或者board目录下。干的事情包括设置系统时钟、初始化DDR控制器或者至少把DDR控制器的基地址映射关系准备好、关看门狗。看门狗这事我得提一嘴很多板卡上电默认看门狗是开的要是不在启动最初把它喂上或者关掉U-Boot还没跑完就被复位了。表现就是板子不断重启串口打印反复从头开始。排查方法很简单在lowlevel_init里加个调试gpio翻转灯看看程序到底跑到哪里被拉回_start了。这个阶段的代码风格通常是“非C友好”的因为此时栈还没设置。你可以在lowlevel_init里用汇编操作寄存器但尽量不要在这里调用比较复杂的C函数。有些平台偏要用C那就必须在进入C之前先把栈指针设好否则一切免谈。3. 从汇编跨进C的桥_main与crt0.S里的“隐秘布局”汇编阶段把CPU环境理清楚之后就会跳转到_main。这个函数在ARMv7上位于arch/arm/lib/crt0.S。它承担的角色极其特殊它本身是汇编但干的事全是给C代码铺路。它也是整个启动流程里最容易出问题的一段因为涉及到了栈分配、重定位和BSS清零三件大事。3.1 栈指针的设定为什么要把栈放在RAM顶端附近_main的第一步通常是加载初始栈地址ldr r0, (CONFIG_SYS_INIT_SP_ADDR) bic r0, r0, #7 /* 8字节对齐 */ mov sp, r0CONFIG_SYS_INIT_SP_ADDR是配置项通常在include/configs/xxx.h或设备树里定义。这个地址的选取有学问。我见过的板子大多把初始栈放在SRAM的高端地址或者DDR初始化前的临时RAM顶端。ARM的栈是向下生长的把栈顶设在高地址栈往下长能尽量避免和正在运行的代码、数据冲突。为什么需要对齐ARM的AAPCS调用标准要求栈指针8字节对齐这样函数内的64位类型操作比如long long也能安全使用。你别小看bic r0, r0, #7这一条指令忘了它在某些编译器选项下strd指令会直接产生对齐异常。这里有个非常容易踩的坑U-Boot在汇编阶段用的栈和重定位后C阶段用的栈不是同一个栈。_main早期设置的栈可能是CPU片内SRAM或者临时内存非常小可能只有几KB只够跑board_init_f等重定位完成会把栈切到DDR里的 безопасная区域。所以你在board_init_f里千万别开大数组一个char buf[4096]可能就把SRAM栈挤爆了。3.2 全称是board_init_f_alloc_reserve——从预留到初始化_main设置完临时栈之后要做一个关键动作调用board_init_f_alloc_reserve。这个函数在common/board_f.c中它的核心作用是在栈上预留足够的空间给后续全局数据gd_t使用。void board_init_f_alloc_reserve(ulong base) { gd (gd_t *)(base - sizeof(gd_t)); gd-start_addr_sp base; }gd_t是U-Boot的全局数据结构里面存放了各种启动过程需要传递的信息比如RAM大小、启动标志、是否已经重定位、环境变量地址等。这个结构体在include/asm-generic/global_data.h中定义。它直接以栈顶向下预留的方式“分配”——没有malloc没有内存管理就是简单的指针偏移。所以整个过程中汇编设置了SPC代码再基于SP往下抠一块给gd。这就是为什么board_init_f_alloc_reserve必须在任何复杂C操作之前调用因为gd指针本身是全局变量如果没预留空间后续所有gd-xxx的操作都等于往随机地址写数据。3.3 哥俩好board_init_f与board_init_r的分工逻辑如果要从整体上把握U-Boot启动board_init_f和board_init_r这一对函数是大纲级的存在。board_init_f全称是board init before relocation它在重定位前执行。你能执行到的初始化包括初始化串口简单版串口debug_uart用于打印早期信息初始化计时器init_timebase为后面的延时函数打底计算RAM大小读控制寄存器或者DDR控制器信息调用dram_init来填gd-ram_size执行setup_ machine_id、reserve_mmu等一些让gd结构更完整的工作最后调用relocate_code把U-Boot自身搬到RAMboard_init_r则是重定位后干的活它才是真正“满血版”的初始化初始化完整串口驱动使用设备树或板级配置初始化Flash和环境变量系统初始化I2C/SPI/GPIO等外设初始化网络展示“U-Boot 2023.04 ... ”的大logo打印调用main_loop进入命令行为什么要把初始化拆成两半因为board_init_f的时候U-Boot还在Flash/SRAM里跑很多功能跑不起来比如要从DDR里读写数据的驱动、要用IMDin-memory distribution做复杂内存操作的逻辑。所以先把轻量级的串口、计时器、内存起来然后把代码搬过去再干重型初始化。4. 重定位整个启动过程最精妙的一步很多人看U-Boot启动看到relocate_code就头大。它确实是整个启动里最微妙的部分我拆开揉碎讲清楚。4.1 为什么要重定位Flash不能写、DDR才能跑完整逻辑U-Boot自身代码最初是在Flash里或者芯片内部ROM里执行的。Flash有两个硬伤读取慢、不能直接写。读取慢这个好理解NOR Flash虽然可以XIP但随机访问性能远低于DDR内存后面要从网络下载内核、解析设备树、写环境变量如果代码还在Flash上跑性能会很难看。不能写就是另一个致命问题环境变量、saveenv、动态修改的设备树都需要写内存Flash不是不能写是写操作麻烦且寿命有限不适合当运行内存用。所以U-Boot的做法是在board_init_f阶段算好自己要占多大空间然后从Flash原封不动把自己拷贝到RAM里再跳到RAM里的新地址继续跑。这个过程就叫重定位。4.2 relocate_code的汇编实现从哪里来、到哪里去、怎么修正relocate_code实现在arch/arm/lib/relocate.S。核心逻辑分三步第一步算偏移。gd-reloc_off记录了重定位前后的地址偏移量。假设U-Boot编译时链接基址是0x87800000实际被拷贝到的RAM基址是0x80000000那么偏移就是0x07800000代码里的所有绝对地址都要加上这个偏移。第二步拷贝。经典的memcpy式循环把__image_copy_start到__image_copy_end之间的所有数据搬过去。这段区间包含了异常向量表、代码段、只读数据段是整个U-Boot镜像的实质内容。第三步修正绝对地址。拷贝完之后代码里的_start_addr、各个函数指针、.rel.dyn段里的重定位表都要逐一更新。这一步比较复杂但核心目的只有一个让代码里引用的地址都指向RAM里的新位置。/* 伪代码示意 */ for (each entry in .rel.dyn) { *(reloc_addr) gd-reloc_off; }在ARM的PIE位置无关可执行文件模式下U-Boot主要靠rel.dyn节进行动态重定位。编译选项里通常会有-fPIE这就是给重定位做铺垫的。4.3 BSS段的清零为什么必须放在重定位之后BSS段是未初始化的全局变量区域C规范规定它必须被清零。汇编里清零BSS的代码是这样的ldr r0, __bss_start ldr r1, __bss_end .Lloop: cmp r0, r1 bhs .Lbss_done mov r2, #0 str r2, [r0], #4 b .Lloop注意一个问题BSS段要清的是RAM里的BSS。如果你在Flash上先把BSS清了然后代码拷到RAMBSS里放的清零标记不就丢了吗所以正确的顺序是拷贝代码到RAM → 重定位 → 清BSS。U-Boot的_main流程正是这样安排的先调relocate_code再清BSS最后跳到RAM里的board_init_r。我见过有人为了调试在relocate_code之前手动清了一次BSS结果全局变量全部归零环境变量缓存直接消失查了半天。后来把清理挪到重定位后问题就消失了。4.4 “旧世界”与“新世界”的切换重定位后跳转时的栈与链接地址重定位完成后board_init_r的入口地址已经变成RAM里的新地址了。这时要注意堆栈指针也必须切到尾部的安全区。这个切换发生在crt0.S里调用board_init_r之前常见的做法是再设置一次SPldr r0, _TEXT_BASE /* 新代码基址 */ ldr sp, [r0, #GD_START_ADDR_SP_OFFSET]这里gd-start_addr_sp在重定位后会被更新为DDR中预留的栈顶。为什么不在重定位前就把SP改成DDR地址因为那时DDR可能刚刚初始化还没有足够空间来放栈而且board_init_f还要调用很多库函数栈太大反而容易和拷贝区域冲突。先小栈跑前段再切大栈跑后段这个设计是考虑过的。5. 走进C世界从board_init_f到main_loop的完整旅程踏过重定位这道坎恭喜你正式进入“C的世界”。不过C世界也分两段前半段是重定位前的board_init_f后半段是重定位后的board_init_r两者经历的是完全不同的初始化深度。5.1board_init_f核心链条串口、DDR、内存规划board_init_f在common/board_f.c里是一张巨大的函数指针数组init_sequence_f[]。它会按顺序执行一组初始化函数常见的有阶段函数干什么调试串口debug_uart_init极早期串口打印时钟init_timebase初始化延时用的时基内存announce_dram_init-dram_init填充gd-ram_size保留reserve_global_data在RAM里预留gd区保留reserve_archARCH相关内存预留保留reserve_mmu预留MMU页表保留reserve_fdt预留设备树加载区最终setup_dest_addr计算目标RAM基址这个数组的元素全是static int (*const func)(void)指针每个函数返回0表示成功返回非0会导致启动中止。我以前调一个板子串口能打印到某一项就停住排查半天发现是某个函数的返回值被改成了错误码U-Boot启动直接卡死。所以看这个数组的顺序对排查启动中断很有帮助。dram_init是特别值得关注的一步。很多新手以为board_init_f里一进来DDR就能用其实不是。DDR控制器初始化通常在更早的lowlevel_init或者SPL阶段完成dram_init只是告诉U-Boot这块板子的内存有多大。它通过读取控制器寄存器或者直接写死配置来填充gd-ram_size。如果dram_init没填对后面内存规划全错拷贝和重定位都会翻车。5.2board_init_r的逻辑顺序顺序错了就直接躺板board_init_r在common/board_r.c里同样是一个init_sequence_r[]数组。这个阶段的初始化函数多了很多挑几个关键的说initr_reloc_global_data修正重定位后的gd指针initr_malloc初始化堆空间U-Boot终于能用malloc了initr_caches启用I-Cache部分平台会连D-Cache一起开initr_mmc/initr_net/initr_usb各类外设驱动stdio_init/console_init_r完整串口与终端初始化initr_env从存储介质加载环境变量initr_announce打印U-Boot启动logboard_init_r的顺序设计有讲究。比如initr_malloc必须在很多需要分配内存的驱动初始化之前因为board_init_f阶段不允许malloc驱动里如果调用了malloc就会踩到未初始化的堆空间。再比如完整串口初始化必须放在stdio之后stdio又是console_init_r的一部分否则你连log都看不全。我调NFS启动时遇到过网络驱动初始化放在环境变量加载之前、导致IP地址解析不出来的问题原因就是initr_net应在initr_env之后。5.3 最终归宿main_loop怎么拿到命令行并执行bootcmdboard_init_r在一长串初始化之后最后会调用run_main_loop()进入main_loop。这个函数在common/main.c里它会做两件事加载启动命令和进入命令行循环。main_loop内部会先检查bootdelay环境变量如果在倒计时内没有按键打断就会自动执行bootcmd里的命令——通常就是bootm、bootz或者booti去引导内核。如果你在这阶段按了任意键就进入交互命令行出现提示符等待你输入命令。有一些调试技巧可以分享如果你想观察U-Boot启动后自动执行了什么可以在main_loop里临时加打印如果不想等bootdelay可以把bootdelay环境变量设为-1立刻进命令行。设成-1这个操作U-Boot是完全支持的很多板子的fastboot模式就是这么配置的。5.4 三种常见的启动介质NOR、NAND、MMC的流程差异说完了通用流程必须提一下启动介质的差异。U-Boot可以从NOR、NAND、eMMC/SD卡启动介质不同前期流程会有明显区别。NOR启动最简单支持XIPCPU上电后可以直接从Flash映射地址开始执行_startU-Boot所有代码可以直接在Flash里跑重定位前不需要把代码拷贝到RAM再执行。NAND启动复杂一些因为NAND不是支持XIP的存储器芯片内部ROM会先把前几K代码通常是SPL拷贝到SRAM执行然后SPL再把完整U-Boot加载到DDR。eMMC/SD启动跟NAND有点类似也是先经过BootROM加载SPL到SRAM再由SPL把U-Boot从分区读出来。这也引出SPL的概念SPLSecondary Program Loader是U-Boot的“瘦身版”专门用来加载完整U-Boot。如果你看到启动log里有U-Boot SPL 2023.04字样就说明板子先跑了SPL再跳进U-Boot主程序。SPL的启动流程和主程序类似也有_start、board_init_f、board_init_r三段只是配置裁剪得特别狠代码体积控制在几十KB以内才能塞进片内SRAM。6. 实战排查手册启动卡住怎么看、怎么定位、怎么解决写到这里理论框架基本齐了。最后上点干到不能再干的干货——启动流程出问题时怎么排查。我按“现象 → 思路 → 操作”的格式整理成速查表都是我实际调试中遇到过的问题。6.1 常见问题速查表现象、原因、解决方法现象可能原因排查/解决上电后串口完全无输出串口初始化失败、DEBUG_UART未打开、时钟树不对检查CONFIG_DEBUG_UART在_start后尽早初始化调试串口测量串口引脚电平打印停在DRAM:后不动DDR初始化失败、dram_init填错容量检查DDR控制器寄存器、时序参数对比官方配置单独编译DDR测试代码反复重启打印从头循环看门狗没关/没喂、栈溢出、程序跑飞在lowlevel_init关看门狗减小board_init_f里的局部数组用LED定位卡点打印几行后卡死在重定位附近.rel.dyn段损坏、拷贝源/目的地址重叠检查__image_copy_start/end是否包含重定位表确认gd-reloc_off计算正确进入命令行后printenv显示环境变量为空环境变量存储介质初始化失败、env分区错误检查CONFIG_ENV_IS_IN_MMC等配置确认env分区偏移执行env default -a恢复默认自动启动不执行bootcmdbootdelay被设为-1、bootcmd为空、bootargs错误printenv bootcmd查看手动输入run bootcmd测试检查启动命令里的地址参数6.2 三个少有人提的细节printascii、debug_uart和JTAG定位第一printascii是个极好用的硬编码函数它在汇编阶段就能用不需要完整串口驱动。你可以在reset之后直接调用它打印一个字符比如mov r0, #U bl printascii如果能看到U出现就说明CPU已经跑到了这里不断往后面加打印就能用“二分法”缩小卡死范围。这个技巧比加LED灯快捷得多。第二CONFIG_DEBUG_UART是U-Boot提供的一套极简串口调试方案。它会用固定寄存器地址操作串口不依赖设备树甚至不需要时钟驱动。只要芯片手册上有串口的寄存器地址填好配置就能用。我自己调试新板卡第一件事就是把这打开后面所有初始化问题都好定位。第三JTAG。串口打印能定位到函数级别但像D-Cache未关闭导致的随机崩溃、指令对齐问题、中断误触发这类问题串口很难看出名堂。这时候接上JTAGOpenOCD arm-none-eabi-gdb在reset和board_init_f打硬件断点单步看寄存器和内存效率提高十倍。需要注意硬件断点的使用——DDR初始化前很多地址是不可访问的断点不要乱设在还没生效的地址上。6.3 一个真实案例DDR初始化延时报错导致的“半路失踪”最后分享一个实际案例。一次调试新板SPL阶段打印正常完整U-Boot的_start也正常但到了重定位跳转后系统就死了串口什么多余信息都没有。我一开始怀疑是重定位拷贝有问题反复查看.rel.dyn也没找到破绽。后来用JTAG挂上去看发现程序死在board_init_r里的一个内存访问指令上。进一步查发现是DDR初始化没做完全。SPL阶段虽然把DDR拉起来了但只初始化了部分bank而完整U-Boot体积较大拷贝时有一部分落在了没初始化的bank地址上。程序本身拷过去了但数据读不出来一执行就崩。这个问题光靠串口很难看出来因为拷贝过程没有校验。解决思路是在relocate_code之后加一段内存回读比对代码把所有拷贝数据读出来和源数据比对立刻就能发现是哪些地址出了问题。现在很多厂商的U-Boot会在SPL里做成dcache关、检测功能的版本就是为了防这个问题。7. 内核跳转一瞬U-Boot最后做了什么main_loop执行bootm引导内核这也是U-Boot整个生涯的最后一步。虽然这一步已经不属于“启动流程”范畴但由于它在main_loop之后紧接着发生我简单提一下关键点。do_bootm会解析内核镜像头部准备好bootargs设置machine id或者传递设备树指针最后通过跳转指令把控制权交给内核入口。这一步如果卡住通常表现为打印Starting kernel ...之后没有任何输出内核可能崩在极早期常见原因是bootargs的console参数错误或者设备树不匹配。内核打印了一点又停住常见原因是DTS里串口节点兼容性不匹配、内存节点和实际DDR配置不一致。复现性随机崩溃常常是D-Cache没有正确关闭或MMU页表配置不对导致内核启动阶段访问内存出问题。U-Boot在跳转内核前会把gd-bd-bi_arch_number设好同时把设备树地址放在r2寄存器。这是ARM Linux启动的硬约束很多定制内核如果U-Boot里传参不对启动就会失败。8. 说说我踩坑后的个人体会U-Boot启动流程说到底是“顺序决定成败”的艺术。汇编阶段管好CPU环境C阶段管好板级资源重定位是分水岭前后环境完全不同。很多问题排查到最后不是某个寄存器值多难配置而是某个初始化函数被放错了位置。所以我把init_sequence_f[]和init_sequence_r[]两个数组完整看了一遍又一遍靠的是死记硬背吗不是。你把每个数组元素的函数名当成一个事件并在脑子里排一张“时间轴”哪怕一开始记不全调试时再回去查具体某个函数做了什么整个图景就会越来越清晰。最后送上一句调试建议新板子移植U-Boot时不要着急调DDR、调网络、调文件系统第一步先让串口亮起来、让复位向量正确、让_start能一路走到main_loop。这一步通了剩下的都是“加水打磨”。我自己每次拿到新板子都会先改两个东西调试串口配置和bootdelay前者保证有眼睛后者保证有手——进命令行手动敲命令总比每次等自动启动失败再重启高效得多。