STM32MP1运行时DDR容量检测：从U-Boot到Linux的完整实现

做嵌入式的朋友应该都遇到过这种需求同一个项目里有的板子焊512MB DDR有的板子焊1GB DDR硬件工程师图省事希望一套系统镜像通吃别为了内存大小维护两套BOOT。有人就问我能不能像PC的BIOS一样开机时自动检测DDR容量然后把内存大小告诉LinuxSTM32MP1上能不能搞我折腾了一周可以明确告诉你能搞但没你想得那么无脑。这篇文章就是把这个需求从原理到实现完整拆一遍包括我最后踩的坑和避坑方法。1. 先理清STM32MP1的启动流程再谈“运行时检测”1.1 STM32MP1上电后DDR到底是谁初始化的说到“BIOS like program”很多人第一反应是写一个独立的小程序像PC BIOS那样自检内存。但在STM32MP1这种MPU上事情不是这样玩的。它上电后先由片内BootROM跑一段固定的代码然后加载FSBL第一级引导程序通常就是TF-A BL2FSBL负责初始化时钟、电源和DDR控制器之后才把控制权交给U-BootU-Boot再引导Linux。也就是说如果你把FSBL和U-Boot合在一起看它们其实就是这颗芯片的“BIOS”。DDR在FSBL阶段被初始化这就带来一个关键限制在FSBL早期DDR控制器和PHY还是断电状态你根本没办法“运行一段程序去测内存大小”。你的代码得先有一套DDR参数把内存初始化好然后才能在那块内存里跑起来。所以所谓的“运行时检测DDR容量”能做的时机其实很窄要么在U-Boot阶段此时DDR已经能用了但参数是写死的要么在FSBL早期根据硬件识别信息去选择不同的DDR training参数。离开这个前提任何“检测”都是空中楼阁。1.2 PC能自动识别内存为什么STM32MP1默认不行PC的BIOS之所以能自动识别内存容量是因为每一根内存条上都有一个SPD EEPROM里面存了容量、时序、厂商、电压等一串标准信息。BIOS上电时通过I2C总线读SPD拿到这批数据后配置内存控制器。这个机制是PC行业标准从几十年前就定好了。STM32MP1开发板几乎都是板载DDR颗粒走线是固定死的没有标准SPD器件。ST官方推荐的开发方式是在PC上用DDR tuning工具针对具体DDR颗粒和PCB设计生成一组DDR配置参数然后把这组参数编译进TF-A镜像里。所以它的DDR参数是“先验”的不是“在运行时发现”的。如果你的板子在量产时只有一种内存那一切好说一旦要兼容两种容量、甚至两种不同厂商的颗粒默认的这套流程就不够用了。1.3 DDR training不是随便改改参数就能跑起来热词里反复出现“DDR training”这里要特别说明一下它主要不是为了“检测容量”而是为了补偿DDR颗粒和PCB布线带来的信号延迟、阻抗不匹配等问题。STM32MP1的DDR控制器和PHY配置里除了常见的CAS Latency、tRCD、tRP还有驱动强度、ODT片上端接、ZQ校准、参考电压等一堆参数。这些参数稍微不对跑起来可能表面正常但高低温一变化就随机死机。所以你想在运行时动态检测DDR容量一定要先想清楚一件事你要检测的只是容量还是连DDR的时序参数也要一起动态调整如果只是容量不同但PHY层参数用同一套能兼容那在U-Boot阶段做检测就够了如果连时序参数都不同那就得回到启动早期在DDR training之前根据硬件状态选择参数工作量会大一个量级。大多数情况下同代DDR3L/DDR4颗粒的基础时序是可以互相兼容的但bank数、行/列地址位数可能不同这些又直接影响容量计算所以不能拍脑袋说“一定能通用”。2. 运行时检测DDR容量的四种思路对比既然要在启动过程中动态获得DDR容量我梳理了四种主流做法先列个表对比一下后面再逐个拆开讲。方案原理优点缺点适用场景地址总线探测U-Boot的get_ram_size()扫描可读写地址判断实际内存边界纯软件实现不需要额外硬件改动最小有访问空洞挂死风险DDR必须按最大容量初始化容量不同但PHY参数兼容的板卡控制器寄存器反推读取DDR控制器里行列bank rank配置字段用公式计算容量安全不碰未知地址速度快读出来只是“配置值”不是真实硬件值寄存器分布因版本而异配合其他方案做确认GPIO/拨码识别硬件根据DDR容量焊接上下拉电阻固件读GPIO选择参数可靠可以在DDR training前决定配置需要硬件预留识别脚改动硬件原理图量产多配置长期维护SPD/EEPROM读取板载或插槽带SPD EEPROM类似PC内存条自动化程度最高最像PC BIOSSTM32MP1主流方案不支持SPD信息也不足以覆盖DDR PHY全部参数定制SO-DIMM或特殊模块板2.1 方案Aget_ram_size()地址探测的原理和风险U-Boot自带一个函数叫get_ram_size()在lib/get_ram_size.c里。它的做法是从内存起始地址开始不断把地址翻倍在每个探测点写入一个特殊数字再读回来比较直到发现数据不一致就认为已经超出了真实内存范围。这背后的本质是地址线没有全部连接实际存储阵列时高位地址会被“折叠”写一个地址的数据会出现在另一个地址上通过回读差异就能推断出有效地址边界。这个方案最诱人的地方在于纯软件不需要硬件改动。但它有一个前提DDR控制器必须在初始化时按最大容量映射。也就是说你得先在TF-A里把DDR配置成1GB然后靠get_ram_size()去分辨实际板子上是512MB还是1GB。如果控制器本身按512MB配置那么即使物理颗粒是1GB你也只能扫到512MB无法“超额”发现容量。风险也很明显DDR控制器是有地址解码器的如果它被配置成支持1GB寻址但物理颗粒只有512MB访问高位空洞地址时可能不会优雅地返回0而是触发AXI总线错误导致CPU直接挂死。所以我建议在使用这个函数前先在目标板上做一轮小范围实验看你的DDR控制器对空洞地址是“回卷”还是“报错”。回卷的话可以放心用报错的话就要配合异常处理或限制扫描范围。2.2 方案B从DDR控制器寄存器反推容量STM32MP1的DDR控制器是基于Synopsys DesignWare方案的控制器里有一组ADDRMAP寄存器用来告诉硬件物理地址的哪几位映射到rank哪几位映射到bank哪几位映射到row哪几位映射到column。你只要把这些字段读出来再用内存容量的标准公式算一下就能得到当前配置的容量。计算方式大概是容量 rank数 × bank数 × 行数 × 列数 × 数据总线位宽 ÷ 8其中行数 2^row_bits列数 2^col_bitsbank数需要根据控制器编码解释。比如读出rank1、bank8、row15、col10数据总线宽度32bit算下来就是 1×8×32768×1024×4字节 1GB和直觉对得上。这个方案的好处是不会真的去访问未知地址所以非常安全适合做启动时的校准确认。但它的缺点也很明显你读到的只是“控制器当前配置”的容量而不是“物理颗粒真实”的容量。如果FSBL里配置就是错的你算出来也是错的解决不了自动识别问题。方案B真正的价值在于当你用其他方式识别到容量后可以读寄存器验证配置是否符合预期。我在项目里就用它做了一个断言万一get_ram_size()返回的和寄存器算出来的不一致就打印一条警告方便定位问题。2.3 方案CGPIO板级识别最推荐量产使用如果你的产品还没完全定型我一定建议在硬件设计阶段预留两个GPIO做DDR容量识别。比如1GB对应GPIO组合00512MB对应012GB对应10。这两个GPIO不需要很精确有上下拉电阻就行。软件上要做的事就简单了在TF-A早期或者U-Boot阶段读取GPIO状态根据状态选择不同的DDR初始化参数。如果两种容量的PHY参数完全一样只需要在U-Boot里把gd-ram_size改成对应值如果PHY参数也不一样那就要在TF-A里准备两套DDR设备树节点在BL2阶段根据GPIO选择其中一套加载。这个方案在嵌入式量产里已经是很成熟的做法了可靠性远高于纯软件扫描。唯一的缺点就是需要硬件配合。但你想一想哪怕这次你不想做运行时识别留两个GPIO也只占两个引脚成本几乎为零后续却可能省掉无数维护多套BOOT镜像的麻烦。2.4 方案DSPD读取理想但不接地气方案D最像PC BIOS也最符合标题里“BIOS like program”的想象硬件上放一个EEPROM里面按照标准格式存DDR容量和时序固件启动时通过I2C读取然后动态配置DDR控制器。但STM32MP1这样的嵌入式平台如果使用板载DDR颗粒基本不会留SPD接口就算你想加DDR PHY还需要ODT、驱动强度、ZQ校准这类颗粒级参数这些通常不在SPD标准定义内容里。所以纯SPD方案看起来很美实际落地时往往还要搭配一份扩展参数表工程复杂度不低。除非你是做像SO-DIMM插槽的模块化板卡否则我不太推荐一开始就奔着SPD去。3. 实操在U-Boot里实现DDR大小自动识别并传给Linux3.1 我的硬件背景和BSP版本为了验证这个需求我在一块STM32MP157A板子上做了实验板载DDR3L容量有两种512MB和1GB。U-Boot版本是2020.10TF-A版本是v2.6Linux内核是5.10。因为硬件没有预留GPIO识别脚SPD更不可能有所以最终选了方案A先让软件跑通“自动识别并传递”这条链路。如果后面发现不同颗粒的PHY参数不兼容我再回头说服硬件加GPIO。这里先说结论如果你的两个DDR容量配置在PHY参数层用同一套训练参数就能通过压力测试那么方案A是完全够用的。如果颗粒相差太远比如一个是DDR3L另一个是DDR4那你无论如何都得走方案C在DDR training之前分叉配置。3.2 第一步把TF-A DDR参数固定配置成最大容量在STM32MP1上DDR配置放在TF-A的设备树节点里ST官方一般会针对不同DDR容量提供不同的DTS文件比如stm32mp157c-ddr3-1g-...和stm32mp157c-ddr3-512m-...。我先把TF-A的DDR参数切到1GB那套确保DDR控制器一开始就按最大映射初始化。具体改动在TF-A的dts文件里类似这样ddr { st,mem-size 0x40000000; /* 1GB */ /* 其他timing参数省略 */ };不同版本的字段名可能不一样比如有的用st,mem-size有的用ddr-size你以ST参考代码为准。关键是让FSBL在初始化DDR时把地址映射扩大到1GB这样后面U-Boot阶段才有机会扫描出真实的512MB边界。改完TF-A后重新编译生成FIP镜像烧录进板子。这里要提醒一句如果512MB颗粒使用1GB配置后training失败那这个方案在你这块板上就提前画上句号了只能转方案C。我用同厂家DDR3L颗粒实测是没问题的。3.3 第二步修改U-Boot的dram_init()用get_ram_size()替换固定值ST官方BSP的U-Boot里board/st/stm32mp1/stm32mp1.c会有dram_init()函数。不同版本实现略有区别有的直接写死有的从TF-A传递的内存信息读取。我把它改成了用get_ram_size()扫描。#define STM32_DDR_BASE 0xC0000000 #define STM32_DDR_MAX_SIZE 0x80000000 /* 1GB */ int dram_init(void) { gd-ram_size get_ram_size((void *)STM32_DDR_BASE, STM32_DDR_MAX_SIZE); return 0; }这里有两个关键点。第一STM32_DDR_BASE要填你板子DDR的物理基地址STM32MP1上一般是0xC0000000但你要去参考手册里确认不要照抄。第二STM32_DDR_MAX_SIZE是你能接受的物理最大容量我这里是1GB所以写0x80000000。如果未来可能出2GB版本那就写0x80000000以上但要注意STM32MP1的DDR寻址上限别超过芯片支持范围。编译U-Boot后烧录启动如果一切正常串口会看到类似这样一行DRAM: 512 MiB如果是1GB的板子就会显示1 GiB。这说明U-Boot阶段已经把容量识别出来了。你也可以在U-Boot命令行敲bdinfo看memsize字段512MB对应0x200000001GB对应0x40000000。3.4 第三步确认内存信息能被传递到LinuxU-Boot启动Linux前会通过设备树把内存信息告诉内核。设备树里对应的/memory节点原本长这样memoryc0000000 { device_type memory; reg 0x0 0xc0000000 0x0 0x20000000; /* 512MB */ };U-Boot在引导内核时会根据gd-ram_size动态更新这个节点的reg属性这个过程由UBoot里的fdt_fixup_memory_banks()完成。如果你用的ST BSP是完整版通常已经默认做了这件事。但为了保险我在板级文件里显式加了一个覆盖函数int ft_board_setup(void *blob, struct bd_info *bd) { int ret; int offset; offset fdt_path_offset(blob, /memory); if (offset 0) return 0; ret fdt_setprop_u32(blob, offset, size, gd-ram_size); if (ret 0) { printf(Failed to set memory size: %s\n, fdt_strerror(ret)); return -1; } return 0; }这个函数会把/memory节点的size属性直接写成U-Boot检测到的gd-ram_size。需要注意如果内存大小超过4GB这个“写32位size”的写法就不对了得用fdt_setprop_u64。在STM32MP1这个平台上最大也就2GB所以32位够用。启动Linux后在终端里执行free -h dmesg | grep Memory cat /proc/meminfo | head -1如果free -h显示512MB而实际板上确实是512MB那就说明整个链路已经打通了。日志里内核初期打印的Memory大小也会和free一致。我对比过启动日志中DRAM: 512 MiB和内核打印的Memory: 511072K/524288K available是对应起来的。3.5 完整启动日志和预期结果下面是一段我实验时的启动日志内容做了脱敏U-Boot 2020.10-stm32mp-r2.1 (Jun 08 2025 - 10:00:00 0800) RAM Configuration: Bank #0: 0xc0000000 512 MiB DRAM: 512 MiB ... ## Loading kernel from FIT Image ... Starting kernel ... [ 0.000000] Linux version 5.10.10 ... [ 0.000000] Memory: 511072K/524288K available如果换成1GB颗粒DRAM和内核打印会变成1 GiB和Memory: 1048000K/1048576K available。整个流程不需要改Linux内核和设备树源文件因为U-Boot在启动时已经替我们改好了。3.6 如果U-Boot从TF-A拿DDR信息应该改哪里在某些ST BSP版本里dram_init()内部不是简单返回一个宏而是调用了一个类似stm32mp1_ddr_size()的函数这个函数会从TF-A传递过来的结构体或某个固定寄存器里读取DDR容量。这种情况下你仍然可以把dram_init()里的实现换成get_ram_size()因为dram_init()在U-Boot获得DDR使用权后被调用此时扫描DDR是合法的。我建议的做法是保留原函数新增一个函数stm32mp1_detect_ram_size()在调试阶段打印出TF-A传递的值和get_ram_size()的值两边对比。如果两者不一致说明TF-A侧配置和设备实际容量不匹配正好能暴露问题。4. 常见问题、排查思路和避坑经验4.1get_ram_size()运行到一半CPU挂死是为什么这是我第一个掉的坑。现象是U-Boot刚打印完DDR基地址就卡死或进入异常。排查下来发现不是get_ram_size()本身有bug而是我在TF-A里配置的最大容量和DDR控制器地址解码方式不匹配导致访问空洞地址时触发了总线错误。解决办法有几个方向。第一确认TF-A配置的内存大小确实覆盖了你要扫描的范围比如要扫1GBTF-A的DDR映射就必须是1GB。第二在U-Boot早期关掉外部中断因为扫描过程中如果来了中断中断处理函数可能正好去访问还没就绪的内存区域增加不稳定因素。第三调试时先把STM32_DDR_MAX_SIZE改小比如256MB确认函数在正常区域能工作再逐步扩大。如果小范围没问题加大范围就挂那基本可以肯定是空洞地址访问问题而不只是参数问题。另外要提醒get_ram_size()会真实地向内存写入测试值。虽然它会保存并恢复现场但在DMA或cache开启的情况下要特别注意一致性。U-Boot早期通常还没启用复杂cache映射所以问题不大如果你是在后期阶段调用记得做cache flush。4.2 容量识别正确但Linux跑几天后随机死机这个问题比上一条更隐蔽。U-Boot和内核都看到了正确容量看起来一切正常但板子在高负载或长时间运行后出现内存CRC错误、进程被kill、甚至整机重启。这往往不是容量识别的问题而是DDR training参数和你的512MB颗粒其实不兼容。你可能会问那为什么启动时没崩溃因为512MB颗粒只用了低地址空间而1GB颗粒的某些时序参数比如刷新率、ODT配置、ZQ校准影响的是整个DDR控制器短期不一定暴露但高低温交替或长时间运行后就会浮现。解决方法是做长期压力测试。可以用Linux下的memtester跑一整轮memtester 400M 5也可以写一个脚本反复读写整个内存区域同时监测温度。如果测出问题就说明这套DDR training参数并不能覆盖两种颗粒这时必须转方案C在硬件上识别出当前用的是哪个容量然后加载对应的DDR参数。软检测能帮你省掉多套BOOT镜像的维护但省不了DDR硬件兼容性验证这个没有捷径。4.3 Linux可用内存始终是设备树里的固定值没有反映检测结果如果U-Boot日志已经正确打印512 MiB但Linux起来后依然是1GB或者512MB中的某一个固定值首先要怀疑设备树有没有被真正修改。在U-Boot命令行里执行fdt print /memory看reg属性是不是已经被更新了。如果没更新排查U-Boot配置里是否有CONFIG_OF_LIBFDT和CONFIG_OF_BOARD_SETUP并确认ft_board_setup()是否被链接进最终镜像。有些时候ST BSP的板级文件里已经有自己的ft_board_setup()但被#ifdef包住了没有被编译。这时候要么把宏打开要么把我们自己的覆盖函数换成它的实现避免函数重名导致链接错误。还有一种快速验证方式在bootargs里加mem512M强制让内核只看512MB。但这只是临时手段产品上不建议依赖因为设备树中的memory节点仍是冲突来源正确做法还是让U-Boot动态修正设备树。4.4 如果你想把“运行时检测”往前移到TF-A早期前面提到的方案A和B都是在DDR已经初始化之后做的严格来说不算“从零开始检测”。如果真要在DDR training之前就确定容量那就必须在TF-A的早期代码里做硬件识别。常见做法是读GPIO或者读I2C上的存在检测引脚。然后根据识别结果选择不同的DDR配置结构体再执行对应的ddr_init()初始化流程。这需要你具备两套DDR参数而且要把两套都编译进TF-A镜像里通过一个条件分支选择。相比U-Boot里做检测这个改动要动到BL2的初始化流程风险更大调试也更麻烦。我个人的建议是除非你的两种DDR颗粒在PHY层面完全不能兼容否则不要一上来就挑战这个方案。先在U-Boot阶段把链路跑通再评估是否值得往早期移动。4.5 最后分享几个实实在在的心得我这段时间最大的体会是标题里这个问题的答案取决于你怎么定义“检测”。如果你只是想知道Linux能看到的DDR有多大那用get_ram_size()配合设备树动态修正完全可以实现代码量也不大。但如果你想做的是像PC BIOS那样无论插什么型号的内存条都能自动适配那在STM32MP1上基本不可能靠单个程序完成因为DDR PHY参数没有统一标准也没有可靠的硬件信息源。所以我后来跟硬件工程师商量在新版原理图里加了一组DDR容量识别GPIO。哪怕当前软件不用以后切换颗粒或者做兼容性验证都会轻松很多。如果你手上还有空间建议也这样设计。嵌入式系统里硬件一个好的决定往往比软件补十个洞更有价值。