1. 项目概述为什么“地址相关码”是u-boot移植中最容易翻车的环节在嵌入式Linux系统启动链里u-boot不是一段“写完编译就能跑”的普通程序——它是一段在CPU裸机状态下、内存尚未初始化、缓存未使能、MMU完全关闭时执行的“前操作系统级代码”。而iTOP-4412这块基于Samsung Exynos4412 SoC的开发板其启动流程又自带典型性ROM Code → BL1iROM→ BL2iRAM中运行→ u-boot从SD卡/EMMC加载到DRAM后跳转。在这个链条里“地址相关码”Position-Dependent Code, PDC就是那个卡在BL2和u-boot交界处、稍有不慎就让板子黑屏、串口无输出、JTAG也抓不到PC值的“幽灵节点”。我带过三届嵌入式实训班每届都有至少5名学员卡在这一步。他们往往能顺利编译出u-boot.bin烧写进SD卡上电后串口只打印出“Starting kernel ...”之前的几行比如“U-Boot 2020.07 (Oct 12 2023 - 14:22:03 0800)”然后戛然而止或者更糟——连第一行都看不到只有空屏和风扇转动声。问题不出在C语言逻辑也不在设备树配置而恰恰出在汇编层最底层的地址跳转、重定位入口、栈指针设置这些“看不见摸不着”的地方。u-boot-2020.07相比早期版本如2012.07或2016.01对链接脚本、重定位机制、CONFIG_SYS_TEXT_BASE等宏定义的耦合度更高而iTOP-4412的DRAM物理地址0x40000000、iRAM起始地址0x02020000、BL2加载位置0x02023400之间存在微妙的偏移关系一旦CONFIG_SYS_TEXT_BASE设为0x43e00000却没同步调整_start符号的链接地址或者arch/arm/cpu/armv7/start.S里bl _main之前没正确设置r0/r1/r2寄存器整个重定位过程就会在memcpy()执行前崩溃。这不是理论推演而是我在某次量产前验证中实测踩过的坑当时把CONFIG_SYS_TEXT_BASE从0x43e00000误写成0x43f00000u-boot在relocate_code()函数里刚执行完ldr r0, __image_copy_start就触发了data abort异常——因为目标地址0x43f00000超出了iTOP-4412实际可用的512MB DRAM范围0x40000000–0x5fffffff而ARMv7的MMU此时尚未开启CPU直接访问非法物理地址导致总线锁死。这种错误不会报错只会静默失败。所以本文不讲“怎么编译”只聚焦“地址相关码”这个生死线从链接脚本的每一行含义到start.S里每个寄存器的使命再到如何用objdump反向验证你的二进制是否真的按预期布局——全部拆解到寄存器级别让你下次面对黑屏时能立刻判断是栈溢出、重定位越界还是.text段被意外覆盖。2. 地址相关码的核心设计逻辑为什么不能全靠CONFIG宏“蒙混过关”很多人以为只要把板级配置头文件include/configs/itop4412.h里的几个宏填对u-boot就能自动适配地址空间。这是对ARM启动流程最大的误解。CONFIG_SYS_TEXT_BASE、CONFIG_SYS_SDRAM_BASE、CONFIG_SYS_INIT_SP_ADDR这些宏本质只是给链接器和汇编代码提供“占位符”它们能否生效取决于三个硬性条件是否同时满足链接脚本的段布局是否与SoC物理地址映射一致、汇编启动代码是否按该布局完成重定位、C运行环境初始化是否在重定位后正确建立。缺一不可且顺序不可逆。2.1 链接脚本u-boot.lds才是真正的“地址宪法”打开u-boot-2020.07/arch/arm/cpu/armv7/u-boot.lds你会看到类似这样的结构SECTIONS { . CONFIG_SYS_TEXT_BASE; . ALIGN(4); .text : { *(.__image_copy_start) *(.text*) ... } . ALIGN(4); .rodata : { *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*))) } ... . ALIGN(4); .data : { *(.data*) } . ALIGN(4); .u_boot_list : { KEEP(*(SORT(.u_boot_list*))); } . ALIGN(4); .image_copy_end : { *(.__image_copy_end) } ... }关键点在于第一行. CONFIG_SYS_TEXT_BASE;——这行不是“建议”而是强制指令链接器必须把接下来第一个段即.text的起始虚拟地址VMA设为CONFIG_SYS_TEXT_BASE的值。但注意这只是VMA不是LMA加载地址。对于u-boot.bin这种flat binaryVMA和LMA默认相同所以CONFIG_SYS_TEXT_BASE既决定了u-boot运行时的入口地址也决定了它被烧写进存储介质后的加载偏移。在iTOP-4412上我们通常将u-boot.bin烧写到SD卡第44扇区sector 44即offset 0x5800由BL2从该位置读取并加载到DRAM中。那么CONFIG_SYS_TEXT_BASE就必须等于这个DRAM加载地址。Exynos4412的DRAM控制器默认映射物理地址0x40000000开始但u-boot不能直接从0x40000000运行因为0x40000000–0x4000ffff64KB被BL2预留作堆栈和临时缓冲区u-boot自身需要约384KB代码数据空间u-boot-2020.07未压缩bin约350KB必须避开Linux内核的加载地址通常0x40600000起。因此行业通用做法是设为0x43e00000即0x40000000 0x3e00000留出62MB安全间隙。但这里有个陷阱如果你在itop4412.h里写了#define CONFIG_SYS_TEXT_BASE 0x43e00000却忘了检查u-boot.lds是否真的被该宏驱动——因为u-boot.lds是通过预处理器包含的其顶部有#include config.h而config.h由mkconfig脚本生成。如果make distclean后没重新执行make itop4412_defconfigconfig.h里可能还是旧值导致链接脚本实际使用的是0x40000000而你却以为是0x43e00000。我见过最离谱的一次是某公司量产固件因CI流水线漏掉defconfig步骤导致1000台设备全部烧录了错误地址的u-boot最终靠JTAG逐台修复。提示每次修改CONFIG_SYS_TEXT_BASE后务必执行make clean make itop4412_defconfig make -j4并用grep TEXT_BASE include/autoconf.mk确认宏值已更新。2.2 汇编启动流程start.S里藏着所有“地址契约”链接脚本定下地址框架而arch/arm/cpu/armv7/start.S则是执行该框架的“契约签署人”。它不关心C语言只操作寄存器其核心任务是在MMU关闭、cache禁用、栈未初始化的绝对裸机环境下把u-boot从加载地址LMA复制到运行地址VMA并跳转执行。这个过程被称作“relocation”而它的成败全系于start.S里几行关键汇编。打开start.S找到_start标签这是u-boot真正入口.globl _start _start: b reset ldr pc, _undefined_instruction ldr pc, _software_interrupt ... reset: /* * set the cpu to SVC32 mode */ mrs r0, cpsr bic r0, r0, #0x1f orr r0, r0, #0xd3 msr cpsr,r0 /* turn off the watchdog */ ... /* Set stack for C code */ ldr sp, CONFIG_SYS_INIT_SP_ADDR ... bl relocate_code这里有两个地址相关命门栈指针sp的设置ldr sp, CONFIG_SYS_INIT_SP_ADDR。这个地址必须位于iRAM中因为DRAM尚未初始化且不能与BL2使用的栈区域重叠。iTOP-4412的iRAM大小为256KB0x02000000–0x0203ffffBL2通常占用0x02020000–0x02023fff所以我们设CONFIG_SYS_INIT_SP_ADDR 0x02024000倒序分配栈空间ARM栈向下增长确保有足够余量。relocate_code的调用时机该函数在arch/arm/lib/relocate.c中实现但它依赖start.S传入的三个参数r0重定位目标地址即CONFIG_SYS_TEXT_BASEr1重定位源地址即u-boot.bin在存储介质中的加载地址由BL2告知r2重定位长度即__image_copy_end - __image_copy_start这三个值必须严格匹配。其中r1不是固定值而是由BL2在跳转前写入r1寄存器BL2会读取SD卡指定扇区将u-boot.bin加载到DRAM某地址再把该地址传给u-boot。如果u-boot的链接地址CONFIG_SYS_TEXT_BASE和BL2实际加载地址不一致memcpy就会把代码复制到错误位置导致后续跳转到非法地址。注意u-boot-2020.07引入了CONFIG_ARMV7_PSCI和CONFIG_ARMV7_SECURE_MONITOR等新选项若启用start.S会插入额外的secure monitor切换代码这会改变寄存器使用惯例。对于iTOP-4412这种无TrustZone的板子必须确保#undef CONFIG_ARMV7_PSCI否则r0/r1/r2可能被意外覆盖。2.3 重定位后的C环境global_data结构体的地址锚点当relocate_code()执行完毕CPU跳转到新的CONFIG_SYS_TEXT_BASE地址继续执行时C语言世界才真正开始。但C代码的第一件事不是初始化串口而是构建一个叫global_datagd_t的全局结构体它存放了整个u-boot运行期的关键状态当前栈顶、DRAM大小、设备树地址、重定位偏移量等。这个结构体的地址由arch/arm/lib/board.c中的board_init_f()函数通过gd (gd_t*)malloc(sizeof(gd_t))分配但malloc此时根本不可用——因为堆还没初始化。真相是global_data被静态分配在链接脚本的.data段末尾其地址由链接器在编译时确定并通过DECLARE_GLOBAL_DATA_PTR宏暴露给C代码。查看include/asm-generic/global_data.h#define DECLARE_GLOBAL_DATA_PTR register volatile gd_t *gd asm (r9)这里强制将gd指针存入r9寄存器。而r9的值是在start.S的relocate_code返回前由mov r9, r4设定的r4则来自ldr r4, __gd_addr——这个__gd_addr符号正是链接脚本里. ALIGN(8); .gd : { *(.gd) }段的起始地址。也就是说global_data的物理地址完全由链接脚本中.gd段的位置决定而该段又必须落在CONFIG_SYS_TEXT_BASE之后、且不与.text/.rodata重叠的安全区域内。如果链接脚本里.gd段被错误地放在了.text段中间或者CONFIG_SYS_TEXT_BASE太小导致.gd被挤到DRAM边界外那么gd-bd-bi_dram[0].size就会读出垃圾值后续mem_malloc_init()初始化堆时就会计算出错误的内存池大小导致malloc分配失败——而u-boot很多关键模块如命令行解析、环境变量加载都依赖malloc。这种错误不会立即崩溃但会在某个看似无关的操作比如输入printenv时突然触发abort。3. 实操全流程从配置修改到二进制验证的七步闭环纸上谈兵不如动手验证。下面是我在线下培训中要求学员必须完成的七步实操闭环每一步都对应一个可验证的输出结果任何一步失败都能准确定位到具体环节。整个过程不依赖JTAG调试器仅用串口SD卡objdump即可完成。3.1 第一步精准配置CONFIG_SYS_TEXT_BASE与配套宏进入u-boot源码根目录编辑include/configs/itop4412.h找到并修改以下宏注意不要删除原有注释保留历史痕迹便于回溯/* iTOP-4412 DRAM layout: 0x40000000 - 0x5fffffff (512MB) */ #define CONFIG_SYS_SDRAM_BASE 0x40000000 #define CONFIG_SYS_TEXT_BASE 0x43e00000 /* u-boot run address */ #define CONFIG_SYS_LOAD_ADDR 0x43e00000 /* default load addr for loady etc */ /* iRAM for early stack: 0x02020000 - 0x0203ffff (256KB), BL2 uses 0x02020000-0x02023fff */ #define CONFIG_SYS_INIT_SP_ADDR 0x02024000 /* stack top in iRAM */ /* Relocation boundaries - must match actual binary size */ #define CONFIG_SYS_MONITOR_LEN 0x60000 /* 384KB for u-boot.bin */ #define CONFIG_SYS_MALLOC_LEN 0x200000 /* 2MB for malloc pool */关键点解析CONFIG_SYS_TEXT_BASE和CONFIG_SYS_LOAD_ADDR必须相同因为u-boot-2020.07默认以CONFIG_SYS_LOAD_ADDR作为tftp/loady命令的加载地址若不一致网络加载的u-boot会运行在错误地址。CONFIG_SYS_MONITOR_LEN不是随便写的它必须大于实际u-boot.bin大小。编译后执行ls -l u-boot.bin我的实测值为0x5a3e0369,632字节所以0x60000393,216字节是安全值。若设得太小relocate_code()在复制时会越界覆盖后续数据。CONFIG_SYS_MALLOC_LEN设为0x2000002MB是为后续Linux内核解压预留空间避免内核镜像覆盖malloc池。实操心得改完后别急着编译先执行make menuconfig进入System configuration→Memory setup确认Text Base Address显示为0x43e00000且Monitor length为0x60000。这是双重校验防止宏定义被其他头文件覆盖。3.2 第二步定制化链接脚本显式声明段边界u-boot-2020.07默认使用arch/arm/cpu/armv7/u-boot.lds但为了绝对可控我建议创建板级专属链接脚本。在board/friendlyarm/itop4412/目录下新建u-boot.lds#include config.h #include asm/sections.h OUTPUT_FORMAT(elf32-littlearm, elf32-littlearm, elf32-littlearm) OUTPUT_ARCH(arm) ENTRY(_start) SECTIONS { . CONFIG_SYS_TEXT_BASE; . ALIGN(4); .text : { *(.__image_copy_start) *(.text*) } . ALIGN(4); .rodata : { *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*))) } . ALIGN(4); .data : { *(.data*) } . ALIGN(4); .gd : { *(.gd) } . ALIGN(4); .u_boot_list : { KEEP(*(SORT(.u_boot_list*))); } . ALIGN(4); .image_copy_end : { *(.__image_copy_end) } . ALIGN(4); .rel_dyn_start : { *(.__rel_dyn_start) } .rel.dyn : { *(.rel*) } .rel_dyn_end : { *(.__rel_dyn_end) } . ALIGN(4); .end : { *(.__end) } _image_binary_end .; }重点改动显式添加.gd段确保global_data有独立、可控的地址空间添加.rel.dyn段为动态重定位预留虽iTOP-4412不用但保持结构完整定义_image_binary_end符号方便后续计算二进制大小。然后修改board/friendlyarm/itop4412/Makefile强制使用该脚本ifdef CONFIG_SPL_BUILD LDSCRIPT : $(srctree)/$(CONFIG_SPL_LDSCRIPT) else LDSCRIPT : $(srctree)/board/friendlyarm/itop4412/u-boot.lds endif3.3 第三步修补start.S加固重定位参数传递打开arch/arm/cpu/armv7/start.S找到relocate_code函数调用前的部分在bl relocate_code之前插入调试代码/* Debug: print r0/r1/r2 before relocation */ ldr r3, 0x43e00000 /* target addr */ cmp r0, r3 beq 1f /* If r0 ! expected, hang here for debug */ 1: /* Set r0 target, r1 source, r2 len */ ldr r0, CONFIG_SYS_TEXT_BASE ldr r1, __image_copy_start ldr r2, __image_copy_end sub r2, r2, r1 /* r2 copy length */ bl relocate_code这段代码强制r0/r1/r2为预期值避免BL2传参错误。同时它在r0不等于0x43e00000时停机方便用串口观察——如果卡在这里说明BL2没正确设置r0问题出在BL2侧。3.4 第四步编译并提取关键地址符号执行完整编译make distclean make itop4412_defconfig make -j4编译成功后用objdump提取关键符号地址这是验证链接是否正确的黄金标准# 查看.text段起始和结束地址 arm-linux-gnueabihf-objdump -h u-boot | grep \.text # 输出应为 1 .text 0005a3e0 43e00000 43e00000 00010000 2**5 CONTENTS, ALLOC, LOAD, READONLY, CODE # 查看__image_copy_start和__image_copy_end arm-linux-gnueabihf-objdump -t u-boot | grep __image_copy # 输出应为 # 43e00000 l d .text 00000000 __image_copy_start # 43e5a3e0 g .text 00000000 __image_copy_end # 查看global_data地址 arm-linux-gnueabihf-objdump -t u-boot | grep _gd # 输出应为43e5a3e0 g .gd 00000000 __gd_addr关键验证点.text的VMA第三列必须等于CONFIG_SYS_TEXT_BASE0x43e00000__image_copy_end - __image_copy_start必须等于0x5a3e0与ls -l u-boot.bin大小一致__gd_addr必须紧随__image_copy_end之后如示例中0x43e5a3e0证明.gd段布局正确。实操心得我习惯写个shell脚本check_layout.sh自动比对这些值一行命令就能发现90%的链接错误。脚本核心逻辑是objdump -t u-boot | awk /__image_copy_start/{s$1} /__image_copy_end/{e$1} END{printf Size: 0x%x\n, strtonum(0xe)-strtonum(0xs)}。3.5 第五步制作SD卡启动镜像精确控制加载位置iTOP-4412的启动ROM从SD卡第44扇区sector 44512字节/扇区读取BL2BL2再从第49扇区读取u-boot.bin。因此我们必须将u-boot.bin烧写到SD卡的正确扇区# 假设SD卡设备为/dev/sdb # 清空前64扇区保留MBR dd if/dev/zero of/dev/sdb bs512 seek1 count63 # 烧写u-boot.bin到sector 49即offset 49*512 0x6200 dd ifu-boot.bin of/dev/sdb bs512 seek49 # 同步写入 sync验证烧写是否准确# 读取sector 49的前16字节应为ARM分支指令ea开头 dd if/dev/sdb bs512 skip49 count1 2/dev/null | hexdump -C | head -n1 # 正常输出00000000 ea 00 00 06 e5 9f 10 00 e5 9f 20 04 e5 9f 30 08 |........ ..0.|这里ea000006是ARM指令b reset跳转到reset标签证明u-boot.bin的_start入口被正确烧写。3.6 第六步串口日志分级调试定位崩溃点连接USB转串口模块115200 8N1上电后观察日志。u-boot-2020.07的日志分为四级Level 0仅打印U-Boot 2020.07...和DRAM:信息Level 1增加MMC:、Loading Environment from MMC...Level 2显示relocate_code执行过程Level 3详细打印每个函数入口。在include/configs/itop4412.h中添加#define CONFIG_SYS_CONSOLE_IS_IN_ENV #define CONFIG_EXTRA_ENV_SETTINGS \ consolettymxc0,115200\0 \ bootdelay3\0 \ baudrate115200\0 \ stdoutserial\0 \ stderrserial\0 \ stdinserial\0 \ verifyn\0 \ loglevel7\0 \ /* 最高日志等级 */loglevel7会强制输出所有DEBUG信息。当板子黑屏时如果串口还能收到relocate_code: src0x43e00000, dst0x43e00000, len0x5a3e0说明重定位已完成如果只收到U-Boot 2020.07...就停止问题一定在relocate_code()内部——大概率是栈溢出或memcpy越界。3.7 第七步用readelf反向验证重定位后地址如果串口无输出需用readelf检查u-boot.bin的重定位表是否正常arm-linux-gnueabihf-readelf -r u-boot | head -20正常输出应包含大量R_ARM_ABS32类型的重定位项指向.text和.data段内的符号。如果输出为空或只有几行说明链接时未生成重定位信息问题出在链接脚本的SECTIONS定义或-pie编译选项缺失。常见问题速查表现象可能原因验证方法串口无任何输出BL2未正确跳转或_start入口被覆盖用逻辑分析仪抓SD卡信号确认sector 44/49读取正常打印U-Boot...后卡住relocate_code()执行中abort在start.S的relocate_code内插入mov r0, #0; swi 0触发软件中断用JTAG捕获PC值DRAM: 0 MiBglobal_data中bd-bi_dram[0].size为0objdump查看__gd_addr附近内存确认gd结构体是否被覆盖Wrong Image Format for bootm commandu-boot.bin被截断或校验失败md5sum u-boot.bin与烧写前对比确认SD卡写入完整性4. 地址相关码的深度避坑指南那些文档里绝不会写的实战经验教科书和官方Wiki只会告诉你“应该怎么做”但真正决定项目成败的往往是“为什么不能那么做”以及“万一做了会怎样”。以下是我在三年内处理27个iTOP-4412相关项目时亲手验证并记录的五大致命陷阱每一个都曾让整块板子变成砖头。4.1 陷阱一CONFIG_SYS_TEXT_BASE与CONFIG_SYS_SDRAM_BASE的“镜像偏移”幻觉很多开发者认为只要CONFIG_SYS_TEXT_BASE CONFIG_SYS_SDRAM_BASE offset就万事大吉。这是危险的幻觉。Exynos4412的DRAM控制器支持bank interleavingBank交错模式当启用该模式时物理地址0x40000000对应的内存单元可能实际分布在两个不同的DRAM chip上而u-boot的重定位memcpy()是线性拷贝它假设地址空间是连续的。如果硬件设计中bank交错配置与u-boot的地址假设冲突memcpy会把代码复制到错误的bank导致后续指令取指失败。真实案例某客户板子在单bank模式下正常切换到双bank交错后u-boot在board_init_r()中调用init_sequence_r[]数组时PC跳转到0x43e000000x123456的地址但该地址实际映射到另一个bank的无效区域。解决方案不是改CONFIG宏而是在board_init_f()中手动禁用bank交错通过写Exynos4412的DRAM_CONCONTROL寄存器0x10020000清除bit[1]。实操心得永远不要假设SoC的地址映射是“理想连续”的。用示波器测量SDRAM_CLK和SDRAM_CKE信号确认bank模式查阅原理图中DRAM芯片型号查其datasheet确认bank组织方式最后在u-boot中添加硬件适配代码而非强行修改地址宏。4.2 陷阱二iRAM栈空间的“隐式竞争”——BL2与u-boot的栈打架CONFIG_SYS_INIT_SP_ADDR设为0x02024000看似安全但BL2在跳转前会把自己的栈顶设为0x02023fff然后执行mov pc, #0x43e00000。问题在于ARM的bl指令会把返回地址压入栈而u-boot的_start入口第一行就是b reset它不保存LR。这意味着BL2的栈帧并未被清理u-boot的栈指针直接覆盖了BL2的栈空间。后果是当u-boot执行到board_init_f()调用malloc()分配内存时malloc内部会使用__libc_malloc而该函数依赖_dl_mmap后者又会调用__default_sa_restorer——这个函数需要保存寄存器到栈但栈底已被BL2数据污染导致r4-r11寄存器被写入垃圾值最终在relocate_code()的memcpy()循环中r0src被意外修改memcpy开始复制错误地址。破解方法在start.S的reset标签后立即清空BL2遗留的栈空间reset: /* Clear BL2 stack residue */ ldr r3, 0x02020000 ldr r4, 0x02024000 mov r5, #0 1: cmp r3, r4 bge 2f str r5, [r3], #4 b 1b 2: /* Then set our own stack */ ldr sp, CONFIG_SYS_INIT_SP_ADDR这段代码将0x02020000–0x02024000共16KB空间清零彻底抹除BL2痕迹。实测后malloc稳定性从70%提升至100%。4.3 陷阱三设备树地址的“双重绑定”——CONFIG_SYS_FDT_BASE的隐藏依赖u-boot-2020.07默认从CONFIG_SYS_FDT_BASE地址加载设备树.dtb文件而该地址必须位于DRAM中且不能与u-boot代码重叠。但很多人忽略了一个事实设备树的memory节点必须与u-boot实际使用的DRAM范围完全一致。例如你的板子有512MB DRAM但设备树中写的是memory40000000 { device_type memory; reg 0x40000000 0x20000000; /* 512MB */ };这看起来正确但如果u-boot的CONFIG_SYS_TEXT_BASE0x43e00000且CONFIG_SYS_MONITOR_LEN0x60000那么u-boot实际占用了0x43e00000–0x43e5a3e0约370KB空间。而Linux内核启动时会读取设备树的memory节点来初始化buddy system如果该节点声称整个0x40000000–0x5fffffff都可用内核就会把u-boot占用的那370KB也纳入内存管理导致u-boot代码被内核无意覆盖。正确做法在设备树中为u-boot预留一块“reserved-memory”reserved-memory { #address-cells 1; #size-cells 1; ranges; uboot_reserved: uboot43e00000 { reg 0x43e00000 0x60000; no-map; }; }; memory { reg 0x40000000 0x20000000; linux,usable-memory 0x40000000 0x1ff00000; /* 减去u-boot预留 */ };这样内核启动时会跳过0x43e00000–0x43e5ffff区域确保u-boot安然无恙。4.4 陷阱四重定位长度的“四舍五入”灾难——ALIGN(64K)的隐形杀手CONFIG_SYS_MONITOR_LEN设为0x60000384KB是安全的但如果你偷懒设为0x60000而实际u-boot.bin是0x5a3e0看似有余量。问题在于u-boot的重定位代码在relocate_code()中会执行for (i 0; i len; i) dst[i] src[i];这里len是字节数没问题。但u-boot-2020.07在arch/arm/lib/cache-cp15.c中为优化cache刷新会按64KB对齐处理。如果len不是64KB的整数倍最后一块cache line64字节可能被错误刷新导致部分代码未被写入DRAM。实测中当len0x5a3e0369,632字节它除以64KB0x10000余0x3e0最后一块0x3e0字节的cache刷新会失败造成board_init_r()函数的前几条指令丢失。解决方案将CONFIG_SYS_MONITOR_LEN设为下一个64KB对齐值。0x5a3e0向上取整到64KB是0x60000所以没问题但如果u-boot.bin是0x5fffff6,291,455字节下一个64