简介海思Hi3531平台U-Boot移植是嵌入式底层开发的重要环节PDF详解了从源码编译、板级适配到DDR3参数调整的全过程适合嵌入式开发者、硬件工程师以及正在做系统启动代码的读者查阅。文档基于海思官方SDK逐步演示解压源码、设置处理器架构与交叉编译环境、拷贝并重命名板级支持目录、修改配置头文件、调整网络物理层地址、注释相关驱动代码并创建一键编译脚本最终生成可烧录镜像。针对外接镁光MT41K256M16HA-125IT内存颗粒文档详细说明DDR控制器寄存器与时序寄存器的修改依据保证内存稳定工作。整个资源只有一个PDF文件大小为1.38MB内容包含命令示例、寄存器对照说明、烧录操作截图以及网络验证结果既能作为新手跟做的教程也可当作日常排错的工作手册。目前已有2518人学习过对正在开展海思平台底层驱动开发的工程师具有较高参考价值。1. 海思3531的u-boot移植为什么先从DDR3参数开始啃拿到一块基于海思3531的板子第一步往往不是去改网卡驱动或串口初始化而是先让DDR3跑起来。u-boot阶段的DDR初始化一旦失败系统连第一行串口log都出不来更谈不上引导内核。很多人在这个环节被卡住不是因为代码看不懂而是因为DDR3的时序参数、寄存器配置和颗粒选型之间的耦合关系不清楚改了一处参数另外几处跟着崩。本文就按“交叉环境—编译流程—DDR3参数配置—烧录验证”这条主线把海思3531的u-boot移植过程拆开讲清楚。内容不会去反复解释u-boot是什么重点放在怎么落地、参数怎么改、怎么验证尤其把DDR3那部分单独拉出来讲透因为这是整个移植过程中最容易被忽略又最容易翻车的环节。适合正在做3531或其他海思平台bring-up的工程师参考。2. 移植前的工程准备交叉工具链与源码目录结构2.1 为什么必须确认交叉编译工具链的版本海思3531的u-boot源码通常由海思官方SDK提供一般放在osdrv目录下。这份代码并不是通用的主线u-boot而是基于某个u-boot版本定制出来的代码风格、驱动框架和最新的主线u-boot有明显差异。编译它不能随手拿一个gcc就上必须使用海思配套的交叉工具链。3531对应的是arm-hisiv300-linux-gcc或arm-hisiv500-linux-gcc两者的区别在于glibc版本和内核头文件版本直接影响最终生成的u-boot二进制能否被HiBoot加载。我一般先执行以下命令确认工具链是否可用arm-hisiv300-linux-gcc -v正常输出里应该能看到完整的版本号信息。如果找不到命令需要先配置环境变量。常见做法是把工具链的bin目录追加到PATH我习惯把这段写进/etc/profile避免每个终端都要重新导出export PATH/opt/hisi-linux/x86-arm/arm-hisiv300-linux/bin:$PATH这里有两点要提醒。第一工具链的版本不能只凭感觉去选必须和SDK里提供的编译器保持一致。3531的SDK一般在osdrv/toolchain目录下自带交叉工具链的压缩包解压后直接使用不要自己去网上下一个所谓最新的arm编译器否则大概率在链接阶段报一堆莫名其妙的问题。第二如果用的是64位宿主机部分老的32位工具链会提示找不到libstdc.so.6或libz.so.1这类库文件这时候需要安装lib32z1、lib32stdc6这些32位兼容库属于环境层面的坑排查半天往往是这个问题。2.2 进入uboot源码目录后先看哪些文件海思3531的u-boot源码目录结构和主线u-boot不太一样。它通常位于osdrv/uboot下顶层有Makefile、config.mk平台相关代码在arch/arm/cpu/armv7/hi3531或类似的路径中。不要一进去就急于修改代码先花5分钟看两个文件boards.cfg和include/configs/hi3531.h。boards.cfg记录了这个平台支持的板级配置项。每个配置项对应一行包含CPU架构、板卡名称、配置文件路径等信息。编译时通过make加目标名来选择对应的板级配置。3531的板级配置一般是hi3531_config或hi3531_full_config之类具体名称以实际SDK版本为准。在hi3531.h这个头文件里能看到u-boot的内存布局、环境变量位置、启动命令等核心配置。比如CONFIG_NR_DRAM_BANKS定义了几块DDR内存区间CONFIG_SYS_SDRAM_BASE定义了内存基地址这些和后续DDR3参数配置直接相关。我在拿到一个陌生板子时会先执行一次完整编译确认默认配置能通过。具体命令如下make ARCHarm CROSS_COMPILEarm-hisiv300-linux- hi3531_config make ARCHarm CROSS_COMPILEarm-hisiv300-linux- -j8编译输出的u-boot.bin就是最终产物但此时它对应的是海思官方开发板的内存配置。如果你的板子上DDR3颗粒容量或位宽与官方板不同就需要进入下一步修改DDR3参数。这一步走完才真正进入ueditor移植的核心环节。3. DDR3参数配置的底层逻辑从颗粒时序到寄存器数值3.1 3531的DDR控制器如何拿到配置参数海思3531的DDR控制器初始化并不像普通平台那样把时序参数硬编码在C代码里而是通过一个独立的二进制配置块来驱动。这个配置块就是reg_info.bin它本质上是一组寄存器的初始化序列由海思提供的小工具或源码生成。u-boot在启动早期会把reg_info.bin加载到内存中逐条解析里面的寄存器地址和值写入DDR控制器相关的寄存器。这就带来一个关键点如果你想修改DDR3参数直接在C代码里改宏定义是没有用的必须把改动反映到reg_info.bin里。SDK中一般会提供ddr相关的源码目录里面包含DDR3颗粒的参数表格和生成脚本。常见的目录名是osdrv/tools/pc/ddr_tool或类似名称里面会看到一份ddr3参数列表按照厂商、型号、容量、位宽对应不同的配置项。这个设计思路的本质是DDR控制器的初始化时序必须与DDR3颗粒的数据手册完全匹配。颗粒的tRCD、tRP、tRAS这些时序参数在寄存器里都是以时钟周期为单位的数值换算关系是寄存器值 时序时间(ns) / 时钟周期(ns)比如DDR3-1600的时钟周期是1.25ns颗粒手册标称tRCD13.75ns那寄存器里就要填13.75 / 1.25 11取整后按规格调整。如果填小了DDR控制器在读写时会提前完成命令切换导致数据采样不稳定填大了虽然更保守但会牺牲内存带宽在需要跑高分辨率视频编码的场景下性能差异明显。3.2 对照DDR3颗粒手册逐项确认的关键参数实际移植时需要关注的DDR3参数集中在几个方面容量与位宽、时序参数、刷新周期、驱动强度。容量与位宽决定了行列地址的映射关系和bank数量。3531的DDR控制器通常支持16bit和32bit两种位宽模式对应的配置项在reg_info.bin中占用不同的配置分支。常见配置组合见下表配置场景颗粒规格位宽总容量典型行列地址2颗DDR3 2Gbit 16bit2Gbit x 1632bit1GBA0-A14, BA0-BA24颗DDR3 2Gbit 8bit2Gbit x 832bit1GBA0-A14, BA0-BA22颗DDR3 4Gbit 16bit4Gbit x 1632bit2GBA0-A15, BA0-BA2配置位宽时有一个常见误区板子上用了2颗16bit的颗粒硬件上接成32bit总线却在配置里只开启16bit模式。这种情况下系统只能识别到一半容量而且地址映射错乱跑压力测试时会随机死机。这属于典型的DDR3参数配置问题排查思路是先确认硬件原理图再对照配置项一一核对。时序参数方面tCLCAS Latency是最容易被忽略的。DDR3的tCL值必须在初始化阶段通过模式寄存器写入它和颗粒的标称频率有严格的对应关系。比如一颗标称DDR3-1600的颗粒在800MHz时钟下可以设置CL11但如果实际运行频率降到400MHz就可以设置更小的CAS延迟来降低访问延迟。海思SDK里的配置通常按频率档位预先定义好了多种组合参数配置时只需要选择对应的频率档和颗粒型号。刷新周期tREFI同样要按颗粒规格填写。标准DDR3的刷新周期是7.8us也就是64ms内需要完成8192次刷新平均每7.8us一次。如果板子工作温度范围很宽比如工业级产品需要根据温度调整刷新频率但这个在3531的配置里一般不用动默认值即可。3.3 生成reg_info.bin的两种常见路径生成新的reg_info.bin有两种途径。一种是修改DDR配置源码后重新编译另一种是使用海思提供的DDR配置工具直接生成。前者的好处是可以看到所有参数的默认值方便理解改动前后差异后者操作更直观适合快速尝试不同颗粒型号。我一般习惯先走源码路径。在ddr_tool目录下找到对应DDR3颗粒的参数定义文件通常是一个头文件或配置文本里面按表格形式列出了不同频率下的寄存器值。修改完成后执行make命令重新生成reg_info.bin再放到u-boot源码指定位置重新编译u-boot。第二种路径是工具生成。海思的工具一般是Windows下的GUI程序界面里可以直接选择DDR3厂商、颗粒型号、频率、位宽点击生成就输出新的配置块。这种方式适合手里有颗粒型号但不想手动计算参数的场景。工具界面里每个下拉框对应一个硬件参数选择完毕后会提示是否覆盖原配置确认后生成新的reg_info.bin。无论走哪条路径最终都需要验证生成的reg_info.bin确实被编入u-boot二进制。验证手段是查看u-boot编译过程的中间文件或者直接反查最终生成的u-boot.bin里包含的配置块内容。具体做法下一章展开。4. 修改DDR3参数配置并在u-boot编译中验证4.1 定位参数定义的位置并理解修改方式拿到一份3521或3531的SDK进入osdrv/tools/pc/ddr_tool目录后先按文件修改时间排序通常最近更新的那个头文件或文本文件就是当前平台使用的DDR配置定义。以常见的ddr3_init.c或ddr_tool.h为例文件里会看到类似下面的结构struct ddr_cfg g_ddr_cfg { .ddr_type DDR_TYPE_DDR3, .ddr_freq 800, /* MHz, 对应DDR3-1600 */ .chip_density DDR_DENSITY_4Gbit, .chip_width DDR_WIDTH_16, .bank_num DDR_BNK_8, .row_addr DDR_ROW_15, .col_addr DDR_COL_10, .tcl 11, /* CAS Latency 11 */ .trcd 11, /* tRCD 11 cycles */ .trp 11, /* tRP 11 cycles */ .tras 28, /* tRAS 28 cycles */ };这段代码的意图很明显确定DDR3类型、运行频率、颗粒密度、位宽、bank和行列地址数量然后给定几个关键时序参数。这里的数值是编译进配置块的默认值如果板子的DDR3颗粒型号变了比如原先是1Gbit颗粒现在换成2Gbit颗粒至少需要修改chip_density和row_addr。修改时为什么row_addr也要跟着改因为DDR3的容量由bank数、行地址数和列地址数共同决定。以2Gbit颗粒为例内部结构是8个bank、行地址15位A0-A14、列地址10位A0-A9总大小就是 8 x 2^15 x 2^10 x 2字节 2Gbit。如果把行地址位配成14位地址空间就会少一半系统能识别到的容量减半。DDR3的行列地址位数与颗粒型号强相关这是硬件设计阶段就定死的软件层面只能去适配不能随意改动。4.2 用脚本核对寄存器的配置值手动改完参数后直接编译不去验证数值是否正确太冒进。DDR时序参数换算时容易出现取整方向的错误比如算出来11.2个周期库里写成了11而实际上DDR控制器要求向上取整到12才能满足时序余量。这种问题在编译期不会暴露要等内存压力测试时才现形。我自己的做法是写一个简单脚本把计划填入的时序参数反算回时间单位和DDR3颗粒手册里的最小值逐项对比# -*- coding: utf-8 -*- # 将DDR时序参数从时钟周期换算为纳秒便于与颗粒手册对照 freq_mhz 800 # DDR时钟频率 clk_ns 1000.0 / freq_mhz # 时钟周期 params { tCL: 11, tRCD: 11, tRP: 11, tRAS: 28, } print(时钟周期: %.3f ns % clk_ns) for name, value in params.items(): time_ns value * clk_ns print(%s %d cycles %.2f ns % (name, value, time_ns))这段脚本的作用是把配置值归一化到时间维度直接和DDR3颗粒手册上标注的绝对时间做对比。颗粒手册给出的tRCD最小值通常是13.125ns或13.75ns如果脚本算出来只有11.25ns说明填小了一个周期需要加1。反过来如果配置值远大于手册最小值说明时序余量足够但性能可能有损失可以根据实际稳定性测试结果决定要不要收紧。参数修改后在ddr_tool目录下重新编译生成配置块然后再回到u-boot目录重新编译完整u-boot镜像。注意两个编译步骤不是同一个Makefile不要试图在u-boot顶层目录里一步生成reg_info.bin。4.3 确认新配置块被编入u-boot镜像修改完参数、重新编译完u-boot之后怎么确认新参数真的进入镜像了直接在源码目录里搜索一个特征值。先找到reg_info.bin或者生成的配置头文件用hexdump导出前32字节hexdump -C reg_info.bin | head -5记下前几个字节的特征值然后再在最终的u-boot.bin里搜索这一串十六进制grep -c $(hexdump -v -e 1/1 %02x reg_info.bin) u-boot.bin如果返回值不为0说明配置已被编入。这个方法比看编译log可靠。编译log可能显示“reg_info.bin已生成”但u-boot.bin里的加载地址不对实际运行时还是会去读DDR控制器内部的默认值。另外也可以让u-boot在启动时打印DDR寄存器的关键配置值。在hi3531.h里开启DDR调试宏比如CONFIG_DDR_DEBUG重新编译后烧录在串口输出里就能看到实际写入DDR控制器的寄存器数值这个数值和reg_info.bin里的配置是否一致一眼能看出来。还有一种隐蔽的错误修改了参数定义但Makefile或链接脚本指向了旧的配置块路径。海思这套SDK里配置块的路径在config.mk中以变量形式存在比如DDR_BIN_PATH。换成新工具链或换电脑后这个变量可能被覆盖或指向默认路径。排查时在u-boot目录下直接搜reg_info.bin这个关键字看所有引用了它的文件里的路径是否一致。5. 烧录验证与稳定性测试DDR3参数有没有配对的判断方法5.1 u-boot阶段先用串口命令确认DDR容量烧录新u-boot后第一步不是直接进内核而是在u-boot命令行里确认DDR是否被正确识别。3531的u-boot支持标准的bdinfo命令输出里会列出内存起始地址和大小。执行后看到的内存大小必须和硬件上的DDR3总容量一致。如果不一致优先怀疑行列地址或位宽配置错误重新检查chip_density和chip_width的设置。容量正确不代表参数最优。时序参数偏保守时容量能识别但性能很差比如视频编码器申请内存耗时翻倍。这时可以执行一遍memtest类的命令。海思u-boot里自带了一个简单的内存测试命令通常叫ddr_test或mem_test用法是在命令行输入起始地址和测试长度ddr_test 0x40000000 0x20000000这是一次覆盖512MB区域的读写测试。这个命令执行期间u-boot会反复对指定内存区域写入0xAA、0x55、0xFFFFFFFF等模式再读回比对。如果执行到中途报错输出中会打印出错的地址和期望值、实际值此时直接去对照出错地址属于哪个bank区域有助于定位是否某根地址线连接异常。同一类错误如果散布在多个地址区间基本都是时序参数过紧导致的采样不稳定。5.2 用长时间压力测试验证时序余量uboot自带的测试虽然有用但覆盖模式相对简单长时间运行才能发现的偶发性错误很难暴露。我会用两种方式做补充。一种是在u-boot命令行里把ddr_test的运行次数调高比如连续跑几百轮ddr_test 0x40000000 0x40000000 1000最后一个参数表示迭代轮数。跑1000轮大约需要额外花费几十秒到几分钟视DDR频率而定。测试期间如果串口无异常输出结束后正常返回命令行基本说明这个区域的读写稳定性没有大问题。另一种方式是在DDR时钟频率的超频边界做反向验证。具体做法是先把DDR频率调高一档比如从800MHz调到933MHz然后重新编译u-boot跑同样的DDR测试。如果高频下能稳定运行说明原频率下的时序余量充足如果高频下立即报错说明原配置接近极限建议降一档频率保证量产稳定性。这个操作的目的不是为了长期运行在超频状态而是通过边界探测试出当前参数是否存在隐患属于验证手段不是推荐配置。5.3 从死机log推测DDR参数的具体问题有时候DDR3参数配置错误不会在测试阶段暴露而是进内核后随机死机或视频解码花屏。这类问题排查起来最抓狂。其中一条典型特征是死机位置不固定有时在内核启动早期有时在应用层运行几小时后。遇到这种问题先看串口最后几行log。如果log在某个地址访问时卡住比如停在pc [c0123456]这类地址上就用反汇编工具查看这个地址属于哪个内核函数。花屏类问题则直接检查DDR频率和显存带宽是否匹配降低频率能缓解的花屏基本指向时序参数余量不足。另外一个容易误导人的现象是DDR测试全通过但系统休眠唤醒后数据损坏。这通常是DDR3的自刷新配置有问题。3531的DDR控制器在低功耗模式下会进入自刷新状态如果自刷新相关的寄存器配置与颗粒不匹配唤醒后部分数据会丢失。症状是唤醒后系统还能运行但之前内存里的数据已经不对了表现为进程崩溃或文件系统损坏。排查时重点审查ddr_tool配置里的刷新周期参数确认与颗粒手册一致。5.4 量产阶段的DDR参数固化建议调试完成、参数确认无误后不要只停留在u-boot能启动这个层面。量产环境下每颗DDR3颗粒的电气特性有离散性时序参数需要在颗粒规格书的允许范围内预留余量。建议最终配置值比推算值额外留出1个时钟周期的余量。这看起来是性能上的浪费但换来的是温度变化和颗粒老化后的稳定性尤其在无风扇散热的产品上DDR3的工作温度可能逼近85摄氏度温度升高会导致时序参数漂移。如果量产批次里出现个别板子偶发死机可以先用本章的测试方法缩小范围确认是DDR参数问题还是硬件虚焊问题。硬件虚焊的表现是同样的配置在部分板子上稳定、部分板子不稳定的随机分布而DDR参数问题在所有板子上表现一致。这一步区分清楚能省下大量盲目调参的时间。别忘了把所有验证过的参数组合记录到产品维护文档里包括DDR频率、时序参数、测试轮数、测试温度方便后续换料或改版时直接复用这套验证基线。本文还有配套的精品资源点击获取