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

做嵌入式的朋友应该都遇到过这种需求：同一个项目里，有的板子焊512MB DDR，有的板子焊1GB DDR，硬件工程师图省事，希望一套系统镜像通吃，别为了内存大小维护两套BOOT。有人就问我，能不能像PC的BIOS一样，开机时自动检测DDR容量，然后把内存大小告诉Linux，STM32MP1上能不能搞？我折腾了一周，可以明确告诉你：能搞，但没你想得那么无脑。这篇文章就是把这个需求从原理到实现完整拆一遍，包括我最后踩的坑和避坑方法。

1. 先理清STM32MP1的启动流程，再谈“运行时检测”

1.1 STM32MP1上电后，DDR到底是谁初始化的

说到“BIOS like program”，很多人第一反应是写一个独立的小程序，像PC BIOS那样自检内存。但在STM32MP1这种MPU上，事情不是这样玩的。它上电后先由片内BootROM跑一段固定的代码，然后加载FSBL（第一级引导程序，通常就是TF-A BL2），FSBL负责初始化时钟、电源和DDR控制器，之后才把控制权交给U-Boot，U-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容量，我梳理了四种主流做法，先列个表对比一下，后面再逐个拆开讲。

2.1 方案A：get_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_bits，bank数需要根据控制器编码解释。比如读出rank=1、bank=8、row=15、col=10，数据总线宽度32bit，算下来就是 1×8×32768×1024×4字节 = 1GB，和直觉对得上。这个方案的好处是不会真的去访问未知地址，所以非常安全，适合做启动时的校准确认。但它的缺点也很明显：你读到的只是“控制器当前配置”的容量，而不是“物理颗粒真实”的容量。如果FSBL里配置就是错的，你算出来也是错的，解决不了自动识别问题。

方案B真正的价值在于：当你用其他方式识别到容量后，可以读寄存器验证配置是否符合预期。我在项目里就用它做了一个断言，万一get_ram_size()返回的和寄存器算出来的不一致，就打印一条警告，方便定位问题。

2.3 方案C：GPIO板级识别，最推荐量产使用

如果你的产品还没完全定型，我一定建议在硬件设计阶段预留两个GPIO做DDR容量识别。比如1GB对应GPIO组合00，512MB对应01，2GB对应10。这两个GPIO不需要很精确，有上下拉电阻就行。

软件上要做的事就简单了：在TF-A早期或者U-Boot阶段读取GPIO状态，根据状态选择不同的DDR初始化参数。如果两种容量的PHY参数完全一样，只需要在U-Boot里把gd->ram_size改成对应值；如果PHY参数也不一样，那就要在TF-A里准备两套DDR设备树节点，在BL2阶段根据GPIO选择其中一套加载。这个方案在嵌入式量产里已经是很成熟的做法了，可靠性远高于纯软件扫描。

唯一的缺点就是需要硬件配合。但你想一想，哪怕这次你不想做运行时识别，留两个GPIO也只占两个引脚，成本几乎为零，后续却可能省掉无数维护多套BOOT镜像的麻烦。

2.4 方案D：SPD读取，理想但不接地气

方案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大小自动识别并传给Linux

3.1 我的硬件背景和BSP版本

为了验证这个需求，我在一块STM32MP157A板子上做了实验，板载DDR3L容量有两种：512MB和1GB。U-Boot版本是2020.10，TF-A版本是v2.6，Linux内核是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对应0x20000000，1GB对应0x40000000。

3.4 第三步：确认内存信息能被传递到Linux

U-Boot启动Linux前，会通过设备树把内存信息告诉内核。设备树里对应的/memory节点原本长这样：

memory@c0000000 { 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配置的内存大小确实覆盖了你要扫描的范围，比如要扫1GB，TF-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里加mem=512M，强制让内核只看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。哪怕当前软件不用，以后切换颗粒或者做兼容性验证，都会轻松很多。如果你手上还有空间，建议也这样设计。嵌入式系统里，硬件一个好的决定，往往比软件补十个洞更有价值。