1. 从一块点不亮的板子说起U-Boot移植到底在解决什么问题很多人第一次接触U-Boot移植场景都差不多手里拿到一块新板子SoC可能是全志、瑞芯微、STM32MP1或者NXP的i.MX系列板子上有DDR、eMMC、串口、网口但上电之后串口一片安静或者只打印几行乱码就卡死。这时候你意识到这块板子缺一个能把硬件叫醒的引导程序而U-Boot就是干这件事的。U-BootUniversal Boot Loader本质是一个裸机程序它的核心职责可以拆成三件事第一完成最基础的硬件初始化把CPU、时钟、DDR、串口这些生命线跑起来第二提供一套命令行环境让你能读写存储、加载内核、烧写镜像第三按照预设流程把操作系统内核从存储介质搬到内存并跳转执行。移植U-Boot就是让这套通用代码在你的具体板子上跑通这三件事。为什么不能直接用厂商给的镜像因为厂商的BSP往往绑定特定板型、特定DDR颗粒、特定外设配置换一块板子、换一颗DDR、改一个引脚就可能起不来。而U-Boot移植的价值在于你掌握了从源码到可启动镜像的完整链路能自己适配新硬件、裁剪功能、定制启动流程。这在车载定制、工业控制、边缘计算设备里是刚需——很多项目要求快速bring-up一块自研板等不了原厂排期。这篇内容适合三类人刚入行的嵌入式工程师想系统搞懂U-Boot移植的完整流程做过驱动但没碰过bootloader的开发者想补齐启动链路这块拼图以及需要为自研板做定制移植的老手想找一些实战细节和避坑经验。我会围绕移植这个动作把配置体系、DDR初始化、串口调试、启动流程、镜像烧写这些核心环节拆开讲尽量给出可直接复现的操作和判断依据。2. 移植前必须搞清楚的U-Boot目录结构与配置体系2.1 源码目录里哪些文件真正和你的板子有关拿到U-Boot源码第一眼会被目录数量吓到但移植时真正高频改动的其实就那么几个位置。以常见的U-Boot 2020之后版本为例核心目录职责如下目录作用移植时是否常改arch/arm/cpu/CPU架构相关初始化一般不改除非新核心arch/arm/dts/设备树文件必改新增板级dtsboard/厂商/板名/板级初始化代码必改新增板级目录configs/板级默认配置defconfig必改新增defconfigdrivers/各类外设驱动按需改如DDR、网口include/configs/板级头文件配置视版本而定common/通用启动流程一般不改关键点在于现代U-Boot已经高度依赖设备树Device Tree和Kconfig配置体系你不再像老版本那样在头文件里堆宏定义而是通过defconfig选功能、通过dts描述硬件。这个转变让移植更规范但也要求你必须看懂dts和Kconfig。2.2 defconfig、dts、board文件三者的分工很多人移植时搞不清这三个东西谁管什么我用一句话概括defconfig管编译哪些功能dts管硬件长什么样board文件管上电后先干什么。configs/xxx_defconfig决定编译进哪些驱动、开启哪些命令、内存布局参数等。比如CONFIG_SPLy决定是否编译SPLCONFIG_DEFAULT_DEVICE_TREExxx指定用哪个dts。arch/arm/dts/xxx.dts描述串口寄存器地址、DDR容量、eMMC控制器、引脚复用等。U-Boot启动时会解析它来初始化硬件。board/厂商/板名/xxx.c提供board_init、dram_init、misc_init_r等钩子函数处理dts描述不了的板级特殊逻辑比如某个GPIO要先拉高才能供电。理解这个分工你就知道遇到问题该去哪个文件找。串口没输出先查dts里的串口节点和defconfig里的CONFIG_DEBUG_UARTDDR容量识别错误查board文件里的dram_init和DDR驱动。2.3 从零新增一块板子的最小改动集假设你要新增一块基于某ARM SoC的板子最小改动集是这样的复制一份相近板子的dts改名为你的板子修改串口、DDR、存储节点。复制一份相近的defconfig改CONFIG_DEFAULT_DEVICE_TREE和板名相关项。在board/厂商/下新建板级目录复制相近板子的board文件改板名和特殊初始化。在arch/arm/dts/Makefile里加入你的dtb编译目标。在board/厂商/的Kconfig里注册你的板子。这五步做完理论上就能make xxx_defconfig make出镜像。但实际能不能启动取决于DDR初始化和串口是否配对。这也是为什么我建议新手先从已有板子改板名开始跑通编译和烧写链路再去动DDR这种高风险部分。提示不要一上来就大改。先让一个已知能跑的配置编译通过并烧进板子确认工具链、烧写方式、串口参数都对再逐步替换成自己的硬件描述。这样出问题时你能快速定位是改坏了还是本来就不通。3. DDR初始化移植里最容易让板子变砖的一环3.1 为什么DDR初始化是移植的分水岭CPU上电后内部SRAM只有几十到几百KB根本装不下U-Boot完整镜像所以必须先把DDR初始化好把代码搬过去。DDR初始化涉及一堆时序参数tRCD、tRP、tRAS、CL、CWL、刷新周期等这些参数由DDR颗粒型号、频率、PCB走线共同决定。参数错了轻则容量识别不对重则直接跑飞、串口无输出。这也是为什么很多移植教程把DDR单独拎出来讲——它是能不能启动和启动后稳不稳的分界线。我见过太多案例串口能打印SPL的几行字然后卡死在DDR初始化或者DDR容量显示只有实际的一半。3.2 用厂商工具生成DDR参数的正确姿势主流SoC厂商都会提供DDR配置工具比如NXP的DDR Tool、瑞芯微的DDR bin生成工具、全志的sys_config等。正确流程是从硬件同事拿到DDR颗粒型号、位宽、频率、PCB层数和走线长度。在厂商工具里填入这些信息工具会算出一组寄存器值。把这组值填到U-Boot的DDR驱动或SPL的DDR初始化代码里。编译烧写看串口是否打印DDR容量和频率。这里有个经验厂商工具算出的参数是理论值实际PCB走线会影响信号完整性。如果工具参数跑不稳可能需要用示波器看DDR时钟和数据线眼图或者适当降频。降频是最省事的验证手段——先用低频跑通再逐步往上提。3.3 DDR容量识别错误的排查链路遇到DDR容量不对按这个顺序查先确认DDR颗粒的rank数和位宽配置对不对。单rank和双rank的初始化流程不同位宽x16和x32的地址映射也不同。再查DDR控制器的地址映射寄存器确认容量计算方式。然后看SPL里dram_init返回的size是否和实际一致。最后用U-Boot命令bdinfo看内存布局用mw/md做读写测试。我踩过的一个坑某板子DDR实际512MBU-Boot只认256MB。查了半天发现是DDR驱动里rank数写死成1而板子用的是双rank颗粒。改成2之后容量正常。这种问题不会报错只会少一半内存非常隐蔽。注意DDR参数改动后一定要做压力测试。简单方法是U-Boot里用mtest命令跑几轮或者加载内核后跑memtester。DDR不稳的表现往往是能启动但跑一会儿就崩比直接起不来更难查。4. 串口调试与SPL让板子开口说话的关键配置4.1 串口没输出的五层排查法串口是移植时的唯一眼睛它不工作基本等于盲调。按从外到内的顺序排查硬件层确认串口线序TX/RX是否交叉、电平TTL还是RS232、波特率。很多板子用的是1.8V电平你接3.3V的USB转串口可能识别不到。引脚复用层查dts里串口节点的pinctrl配置确认引脚mux到了UART功能而不是GPIO。时钟层串口时钟源和分频是否正确。时钟不对波特率就错打印出来是乱码。驱动层确认defconfig里开了对应串口驱动比如CONFIG_DEBUG_UART和CONFIG_DEBUG_UART_BASE。初始化时机如果SPL阶段没输出但U-Boot阶段有说明SPL的串口初始化没配。我一般会先用CONFIG_DEBUG_UART打开早期调试串口它能在DDR还没初始化时就用SRAM打印是定位卡在哪一步的利器。4.2 SPL和U-Boot proper的分工与衔接SPLSecondary Program Loader是个精简版U-Boot体积通常几十KB负责初始化DDR、时钟然后把完整的U-Boot从存储加载到DDR。它的存在是因为SRAM太小装不下完整U-Boot。移植时SPL相关配置集中在defconfigCONFIG_SPLy CONFIG_SPL_TEXT_BASE0x... # SPL运行地址通常是SRAM CONFIG_SPL_STACK0x... # SPL栈地址 CONFIG_SPL_BSS_START_ADDR0x... CONFIG_SPL_DMy # SPL是否用驱动模型常见问题是SPL的链接地址和实际SRAM不匹配导致跑飞。这个地址必须查SoC手册的SRAM映射不能猜。4.3 用early debug定位卡死位置当串口完全没输出时可以用GPIO翻转法在SPL的关键函数入口翻转一个GPIO用示波器或LED看它走到哪。更规范的做法是打开CONFIG_DEBUG_UART它会在board_init_f早期就初始化串口。还有一种情况是串口有输出但卡在某一行比如卡在DRAM:之后。这说明DDR初始化有问题回到上一节的排查链路。卡在MMC:说明存储控制器初始化失败查dts里的mmc节点和时钟。5. 启动流程与镜像烧写从编译产物到板子跑起来5.1 U-Boot启动流程的四个阶段理解启动流程出问题时才知道卡在哪阶段一ROM Code。SoC内部固化的代码根据启动引脚BOOT_MODE决定从eMMC、SD、SPI Flash还是USB启动加载SPL到SRAM。阶段二SPL。初始化DDR、时钟加载U-Boot proper到DDR跳转。阶段三U-Boot proper。初始化外设进入命令行或自动启动。阶段四加载内核。从存储读取内核镜像和设备树跳转执行。移植时最常出问题的是阶段一到阶段二的衔接也就是SPL的镜像格式和启动介质是否匹配。比如eMMC启动要求SPL写在特定偏移SD启动要求有特定的头部。5.2 镜像格式与烧写方式的选择不同启动介质对应不同镜像格式启动介质镜像格式烧写工具SD卡裸镜像分区dd命令eMMC裸镜像分区fastboot/厂商工具SPI Flash带头部镜像烧写器/uboot内sf命令USB厂商专用格式厂商下载工具以SD卡为例典型烧写是sudo dd ifu-boot-with-spl.bin of/dev/sdX bs512 seek1 convfsyncseek1是因为SD卡第一个扇区通常留给分区表SPL从第二个扇区开始。这个偏移因SoC而异必须查手册。5.3 环境变量与启动脚本的定制U-Boot跑起来后bootcmd和bootargs决定怎么启动内核。bootcmd是自动执行的命令序列bootargs是传给内核的参数。移植时经常需要改这两项比如指定rootfs在eMMC的哪个分区、console用哪个串口。我习惯把启动脚本放在环境变量里而不是编译进代码这样改启动参数不用重新编译。用saveenv保存到存储下次上电自动加载。但要注意如果环境变量区没初始化好saveenv会失败这时候需要检查defconfig里的CONFIG_ENV_IS_IN_*配置和存储偏移。提示调试阶段建议把bootdelay设长一点比如5秒给自己留出按任意键进命令行的机会。量产时再改回0或1秒。6. 移植过程中那些文档不会写的坑6.1 工具链版本不匹配导致的诡异错误U-Boot对工具链版本有要求太新或太旧都可能编译失败或运行异常。我遇到过用gcc 12编译老版本U-Boot链接出来的镜像跑飞换gcc 9就正常。原因是新工具链的默认优化和段布局变了。建议用SoC厂商推荐的工具链版本或者U-Boot源码doc/里注明的版本。如果必须用新工具链注意检查-march、-mtune和链接脚本是否兼容。6.2 设备树节点顺序引发的初始化依赖问题设备树里节点的顺序有时会影响初始化顺序尤其是用了u-boot,dm-pre-reloc标记的节点。如果某个驱动依赖另一个驱动先初始化但dts里顺序反了就可能失败。解决办法是显式用u-boot,dm-pre-reloc和bootph-all等属性控制而不是依赖默认顺序。6.3 从能启动到能量产还差什么能启动只是第一步。量产还要考虑启动时间优化裁剪不必要的驱动和命令、环境变量冗余存储、A/B分区升级、安全启动签名。这些在移植阶段就要预留配置比如defconfig里打开CONFIG_ENV_IS_IN_MMC并规划好偏移不然后期改起来要动分区表。我在实际项目里的体会是移植U-Boot最耗时的不是写代码而是建立可靠的调试手段。串口、GPIO翻转、early debug这几样配齐大部分问题都能定位。反过来如果只靠改一改编译烧写看结果效率极低还容易把板子搞成砖。另外DDR参数和启动介质偏移这两个东西一定要以SoC手册为准网上的教程只能参考因为板级差异太大了。最后分享一个小技巧把每次能启动的配置用git打tag改坏了随时回退比记笔记靠谱得多。 
长河君 · 2026/10/7 7:39:26 · 阅读 1.2k U-Boot移植实战：从DDR初始化到串口调试的完整指南
1. 从一块点不亮的板子说起U-Boot移植到底在解决什么问题很多人第一次接触U-Boot移植场景都差不多手里拿到一块新板子SoC可能是全志、瑞芯微、STM32MP1或者NXP的i.MX系列板子上有DDR、eMMC、串口、网口但上电之后串口一片安静或者只打印几行乱码就卡死。这时候你意识到这块板子缺一个能把硬件叫醒的引导程序而U-Boot就是干这件事的。U-BootUniversal Boot Loader本质是一个裸机程序它的核心职责可以拆成三件事第一完成最基础的硬件初始化把CPU、时钟、DDR、串口这些生命线跑起来第二提供一套命令行环境让你能读写存储、加载内核、烧写镜像第三按照预设流程把操作系统内核从存储介质搬到内存并跳转执行。移植U-Boot就是让这套通用代码在你的具体板子上跑通这三件事。为什么不能直接用厂商给的镜像因为厂商的BSP往往绑定特定板型、特定DDR颗粒、特定外设配置换一块板子、换一颗DDR、改一个引脚就可能起不来。而U-Boot移植的价值在于你掌握了从源码到可启动镜像的完整链路能自己适配新硬件、裁剪功能、定制启动流程。这在车载定制、工业控制、边缘计算设备里是刚需——很多项目要求快速bring-up一块自研板等不了原厂排期。这篇内容适合三类人刚入行的嵌入式工程师想系统搞懂U-Boot移植的完整流程做过驱动但没碰过bootloader的开发者想补齐启动链路这块拼图以及需要为自研板做定制移植的老手想找一些实战细节和避坑经验。我会围绕移植这个动作把配置体系、DDR初始化、串口调试、启动流程、镜像烧写这些核心环节拆开讲尽量给出可直接复现的操作和判断依据。2. 移植前必须搞清楚的U-Boot目录结构与配置体系2.1 源码目录里哪些文件真正和你的板子有关拿到U-Boot源码第一眼会被目录数量吓到但移植时真正高频改动的其实就那么几个位置。以常见的U-Boot 2020之后版本为例核心目录职责如下目录作用移植时是否常改arch/arm/cpu/CPU架构相关初始化一般不改除非新核心arch/arm/dts/设备树文件必改新增板级dtsboard/厂商/板名/板级初始化代码必改新增板级目录configs/板级默认配置defconfig必改新增defconfigdrivers/各类外设驱动按需改如DDR、网口include/configs/板级头文件配置视版本而定common/通用启动流程一般不改关键点在于现代U-Boot已经高度依赖设备树Device Tree和Kconfig配置体系你不再像老版本那样在头文件里堆宏定义而是通过defconfig选功能、通过dts描述硬件。这个转变让移植更规范但也要求你必须看懂dts和Kconfig。2.2 defconfig、dts、board文件三者的分工很多人移植时搞不清这三个东西谁管什么我用一句话概括defconfig管编译哪些功能dts管硬件长什么样board文件管上电后先干什么。configs/xxx_defconfig决定编译进哪些驱动、开启哪些命令、内存布局参数等。比如CONFIG_SPLy决定是否编译SPLCONFIG_DEFAULT_DEVICE_TREExxx指定用哪个dts。arch/arm/dts/xxx.dts描述串口寄存器地址、DDR容量、eMMC控制器、引脚复用等。U-Boot启动时会解析它来初始化硬件。board/厂商/板名/xxx.c提供board_init、dram_init、misc_init_r等钩子函数处理dts描述不了的板级特殊逻辑比如某个GPIO要先拉高才能供电。理解这个分工你就知道遇到问题该去哪个文件找。串口没输出先查dts里的串口节点和defconfig里的CONFIG_DEBUG_UARTDDR容量识别错误查board文件里的dram_init和DDR驱动。2.3 从零新增一块板子的最小改动集假设你要新增一块基于某ARM SoC的板子最小改动集是这样的复制一份相近板子的dts改名为你的板子修改串口、DDR、存储节点。复制一份相近的defconfig改CONFIG_DEFAULT_DEVICE_TREE和板名相关项。在board/厂商/下新建板级目录复制相近板子的board文件改板名和特殊初始化。在arch/arm/dts/Makefile里加入你的dtb编译目标。在board/厂商/的Kconfig里注册你的板子。这五步做完理论上就能make xxx_defconfig make出镜像。但实际能不能启动取决于DDR初始化和串口是否配对。这也是为什么我建议新手先从已有板子改板名开始跑通编译和烧写链路再去动DDR这种高风险部分。提示不要一上来就大改。先让一个已知能跑的配置编译通过并烧进板子确认工具链、烧写方式、串口参数都对再逐步替换成自己的硬件描述。这样出问题时你能快速定位是改坏了还是本来就不通。3. DDR初始化移植里最容易让板子变砖的一环3.1 为什么DDR初始化是移植的分水岭CPU上电后内部SRAM只有几十到几百KB根本装不下U-Boot完整镜像所以必须先把DDR初始化好把代码搬过去。DDR初始化涉及一堆时序参数tRCD、tRP、tRAS、CL、CWL、刷新周期等这些参数由DDR颗粒型号、频率、PCB走线共同决定。参数错了轻则容量识别不对重则直接跑飞、串口无输出。这也是为什么很多移植教程把DDR单独拎出来讲——它是能不能启动和启动后稳不稳的分界线。我见过太多案例串口能打印SPL的几行字然后卡死在DDR初始化或者DDR容量显示只有实际的一半。3.2 用厂商工具生成DDR参数的正确姿势主流SoC厂商都会提供DDR配置工具比如NXP的DDR Tool、瑞芯微的DDR bin生成工具、全志的sys_config等。正确流程是从硬件同事拿到DDR颗粒型号、位宽、频率、PCB层数和走线长度。在厂商工具里填入这些信息工具会算出一组寄存器值。把这组值填到U-Boot的DDR驱动或SPL的DDR初始化代码里。编译烧写看串口是否打印DDR容量和频率。这里有个经验厂商工具算出的参数是理论值实际PCB走线会影响信号完整性。如果工具参数跑不稳可能需要用示波器看DDR时钟和数据线眼图或者适当降频。降频是最省事的验证手段——先用低频跑通再逐步往上提。3.3 DDR容量识别错误的排查链路遇到DDR容量不对按这个顺序查先确认DDR颗粒的rank数和位宽配置对不对。单rank和双rank的初始化流程不同位宽x16和x32的地址映射也不同。再查DDR控制器的地址映射寄存器确认容量计算方式。然后看SPL里dram_init返回的size是否和实际一致。最后用U-Boot命令bdinfo看内存布局用mw/md做读写测试。我踩过的一个坑某板子DDR实际512MBU-Boot只认256MB。查了半天发现是DDR驱动里rank数写死成1而板子用的是双rank颗粒。改成2之后容量正常。这种问题不会报错只会少一半内存非常隐蔽。注意DDR参数改动后一定要做压力测试。简单方法是U-Boot里用mtest命令跑几轮或者加载内核后跑memtester。DDR不稳的表现往往是能启动但跑一会儿就崩比直接起不来更难查。4. 串口调试与SPL让板子开口说话的关键配置4.1 串口没输出的五层排查法串口是移植时的唯一眼睛它不工作基本等于盲调。按从外到内的顺序排查硬件层确认串口线序TX/RX是否交叉、电平TTL还是RS232、波特率。很多板子用的是1.8V电平你接3.3V的USB转串口可能识别不到。引脚复用层查dts里串口节点的pinctrl配置确认引脚mux到了UART功能而不是GPIO。时钟层串口时钟源和分频是否正确。时钟不对波特率就错打印出来是乱码。驱动层确认defconfig里开了对应串口驱动比如CONFIG_DEBUG_UART和CONFIG_DEBUG_UART_BASE。初始化时机如果SPL阶段没输出但U-Boot阶段有说明SPL的串口初始化没配。我一般会先用CONFIG_DEBUG_UART打开早期调试串口它能在DDR还没初始化时就用SRAM打印是定位卡在哪一步的利器。4.2 SPL和U-Boot proper的分工与衔接SPLSecondary Program Loader是个精简版U-Boot体积通常几十KB负责初始化DDR、时钟然后把完整的U-Boot从存储加载到DDR。它的存在是因为SRAM太小装不下完整U-Boot。移植时SPL相关配置集中在defconfigCONFIG_SPLy CONFIG_SPL_TEXT_BASE0x... # SPL运行地址通常是SRAM CONFIG_SPL_STACK0x... # SPL栈地址 CONFIG_SPL_BSS_START_ADDR0x... CONFIG_SPL_DMy # SPL是否用驱动模型常见问题是SPL的链接地址和实际SRAM不匹配导致跑飞。这个地址必须查SoC手册的SRAM映射不能猜。4.3 用early debug定位卡死位置当串口完全没输出时可以用GPIO翻转法在SPL的关键函数入口翻转一个GPIO用示波器或LED看它走到哪。更规范的做法是打开CONFIG_DEBUG_UART它会在board_init_f早期就初始化串口。还有一种情况是串口有输出但卡在某一行比如卡在DRAM:之后。这说明DDR初始化有问题回到上一节的排查链路。卡在MMC:说明存储控制器初始化失败查dts里的mmc节点和时钟。5. 启动流程与镜像烧写从编译产物到板子跑起来5.1 U-Boot启动流程的四个阶段理解启动流程出问题时才知道卡在哪阶段一ROM Code。SoC内部固化的代码根据启动引脚BOOT_MODE决定从eMMC、SD、SPI Flash还是USB启动加载SPL到SRAM。阶段二SPL。初始化DDR、时钟加载U-Boot proper到DDR跳转。阶段三U-Boot proper。初始化外设进入命令行或自动启动。阶段四加载内核。从存储读取内核镜像和设备树跳转执行。移植时最常出问题的是阶段一到阶段二的衔接也就是SPL的镜像格式和启动介质是否匹配。比如eMMC启动要求SPL写在特定偏移SD启动要求有特定的头部。5.2 镜像格式与烧写方式的选择不同启动介质对应不同镜像格式启动介质镜像格式烧写工具SD卡裸镜像分区dd命令eMMC裸镜像分区fastboot/厂商工具SPI Flash带头部镜像烧写器/uboot内sf命令USB厂商专用格式厂商下载工具以SD卡为例典型烧写是sudo dd ifu-boot-with-spl.bin of/dev/sdX bs512 seek1 convfsyncseek1是因为SD卡第一个扇区通常留给分区表SPL从第二个扇区开始。这个偏移因SoC而异必须查手册。5.3 环境变量与启动脚本的定制U-Boot跑起来后bootcmd和bootargs决定怎么启动内核。bootcmd是自动执行的命令序列bootargs是传给内核的参数。移植时经常需要改这两项比如指定rootfs在eMMC的哪个分区、console用哪个串口。我习惯把启动脚本放在环境变量里而不是编译进代码这样改启动参数不用重新编译。用saveenv保存到存储下次上电自动加载。但要注意如果环境变量区没初始化好saveenv会失败这时候需要检查defconfig里的CONFIG_ENV_IS_IN_*配置和存储偏移。提示调试阶段建议把bootdelay设长一点比如5秒给自己留出按任意键进命令行的机会。量产时再改回0或1秒。6. 移植过程中那些文档不会写的坑6.1 工具链版本不匹配导致的诡异错误U-Boot对工具链版本有要求太新或太旧都可能编译失败或运行异常。我遇到过用gcc 12编译老版本U-Boot链接出来的镜像跑飞换gcc 9就正常。原因是新工具链的默认优化和段布局变了。建议用SoC厂商推荐的工具链版本或者U-Boot源码doc/里注明的版本。如果必须用新工具链注意检查-march、-mtune和链接脚本是否兼容。6.2 设备树节点顺序引发的初始化依赖问题设备树里节点的顺序有时会影响初始化顺序尤其是用了u-boot,dm-pre-reloc标记的节点。如果某个驱动依赖另一个驱动先初始化但dts里顺序反了就可能失败。解决办法是显式用u-boot,dm-pre-reloc和bootph-all等属性控制而不是依赖默认顺序。6.3 从能启动到能量产还差什么能启动只是第一步。量产还要考虑启动时间优化裁剪不必要的驱动和命令、环境变量冗余存储、A/B分区升级、安全启动签名。这些在移植阶段就要预留配置比如defconfig里打开CONFIG_ENV_IS_IN_MMC并规划好偏移不然后期改起来要动分区表。我在实际项目里的体会是移植U-Boot最耗时的不是写代码而是建立可靠的调试手段。串口、GPIO翻转、early debug这几样配齐大部分问题都能定位。反过来如果只靠改一改编译烧写看结果效率极低还容易把板子搞成砖。另外DDR参数和启动介质偏移这两个东西一定要以SoC手册为准网上的教程只能参考因为板级差异太大了。最后分享一个小技巧把每次能启动的配置用git打tag改坏了随时回退比记笔记靠谱得多。