以太网在跑，画面突然黑了。更麻烦的是，它不是每次必现，而是在特定负载与时序下才出现。
定位结果指向一个跨模块的时序冲突：GMAC1 的访问路径，与 DDR 变频流程在同一个时间窗口内发生了冲突。
本文从现象、通路、根因和修复四个层面，复盘这次问题。
01现象：概率性黑屏挂死
问题出现在GMAC1 以太网传输与DDR 变频叠加的场景：系统可能出现黑屏、挂死，但并不是每次都会触发。
“概率性”是这类问题最麻烦的地方。它意味着：
▸ 单独跑以太网，可能完全正常；
▸ 单独做 DDR 变频，也可能完全正常；
▸ 只有两者在特定时间窗口内相遇，问题才会暴露；
▸ 一旦挂死，显示输出停止，用户看到的就是黑屏。
所以，这类故障很难靠“单模块复现”定位。真正的线索，往往藏在两个模块的交界处。
02背景：三条路径的交汇点
GMAC1是以太网控制器，通过 DMA 在内存与网络之间搬运数据。只要网络吞吐上来，它就会持续、密集地向总线和 DDR 发起访问。
CCI / 系统总线负责连接处理器、外设与内存，是访存请求的必经之路。高吞吐外设的压力，最终都会汇聚到这里。
DDR 变频则是另一条独立的控制路径。频率和电压的切换不是简单改一个分频系数，它需要在一段时间内协调总线、控制器与访存主设备。这个协调过程，通常由底层固件bl31参与完成。
图 1：GMAC1 数据通路与 DDR 变频控制路径
平时，这三条路径各司其职。但在 DDR 变频的切换窗口里，它们必须在同一套总线上协调——这正是冲突的起点。
03根因：一个时间窗口里的路径冲突
定位结论很明确：GMAC1 的 CCI 访问与 DDR 变频期间的访问路径发生冲突。
可以把过程理解为下面这条链：
图 2：高吞吐访问与 DDR 变频窗口的冲突过程
这里有三个关键点：
第一，访问是持续性的。以太网流量不是一次性的，GMAC1 会反复发起 DMA，导致冲突窗口被命中的概率上升。
第二，变频窗口是有限的。只有在 DDR 频率切换的特定阶段，访问路径才处于“需要协调”的状态。窗口越窄，问题越像偶发。
第三，后果是系统级的。DDR 访问异常会沿着总线向上游扩散，最终表现为传输挂起、系统失去响应；显示同样依赖 DDR 带宽，于是黑屏成为最直观的外在表现。
换句话说，这不是某一个驱动的普通 bug，而是跨模块时序协调不完整导致的问题。
04修复：把规避逻辑放到 bl31
修复方案是：将 bl31 升级到 V1.15 及以上版本。新版本在软件层面修复了 DDR 变频期间对冲突路径的访问，避免 GMAC1 的高吞吐访问与变频流程“撞车”。
为什么放在 bl31，而不是 GMAC 驱动或应用层？
▸ DDR 变频的底层协调发生在固件层，bl31 正好处在能统一管理时钟、电源与访存路径的位置；
▸ 把规避逻辑放在这一层，不需要修改 GMAC 驱动，也不需要上层应用配合；
▸ 一次修复可以覆盖不同操作系统和业务形态，避免在各处重复打补丁。
图 3：修复、回归与上线观察闭环
需要注意，这是一项有版本门槛的修复。现场排查时，先确认设备上的 bl31 版本是否已经达到 V1.15 或更高，再判断问题是否仍在修复覆盖范围内。
05影响范围与升级建议
| 问题类型 | 概率性系统挂死（修复类） |
| 影响组件 | DDR 子系统 |
| 受影响平台 | RK3572 相关平台配置 |
| 修复位置 | bl31 固件 |
| 修复版本 | V1.15 及以上 |
| 更新建议 | 建议尽快升级 |
| 补丁影响 | 对正常业务无额外影响 |
| 回归结果 | 测试正常 |
适配范围覆盖多个在维护的 SDK 版本。实际升级时，建议按完整固件包更新，避免只替换单个镜像造成版本不匹配。
06验证与工程启示
修复后的回归测试结果正常。对于这类概率性时序问题，建议在验证阶段增加组合场景的压力测试：
□以太网持续大流量收发，同时让 DDR 变频频繁触发；
□覆盖不同流量模型、不同频率切换策略与长时间运行；
□关注串口与内核日志中是否出现总线超时、访问异常；
□确认现场设备的 bl31 版本，避免“修复未覆盖”的误判。
从工程角度看，这次问题也留下了几点可复用的经验：
1. 概率性挂死，优先怀疑跨模块时序，而不是单点驱动；
2. 高吞吐外设与 DVFS 是一组典型的风险组合；
3. 修复层级应选在能统一协调资源的固件层，而不是各模块各自规避；
4. 有版本门槛的修复，要确保现场可核查、可验证。
07结语
这类问题的难点不在修复本身，而在定位：单看 GMAC，正常；单看 DDR，也正常；问题只在两者相遇的瞬间出现。
把规避逻辑放到 bl31，本质上是在更高一层统一协调访问路径。对嵌入式系统而言，性能、功耗与稳定性往往共享同一套总线资源，理解它们的时序关系，比单独优化某一个模块更重要。
推荐阅读：
