企业官网建设流程全解析

手头正好在调一块全志H618的板子，DDR和HDMI的问题来回折腾了快两周，很多朋友问我这芯片的硬件测试到底怎么下手。这块芯片现在大量用在电视盒子、开源开发板和一些低成本Linux平板方案里，四核A53加内置DDR控制器和HDMI 2.0的集成度，做消费类硬件确实很省事，但也意味着硬件测试的重点非常集中：DDR能不能稳，HDMI能不能出画面，基本决定了这块板子能不能量产。这篇文章就把我实际踩过的坑、用过的仪器、测过的波形和排查思路完整记录下来，给正在做H618方案或者类似ARM平台硬件的朋友一个可以直接抄的测试路径。

先说清楚这篇文章适合谁看：如果你是要做H618核心板、整机主板硬件工程师，或者是搞嵌入式Linux但需要配合硬件验证的软件工程师，再或者是刚入行想搞清楚DDR和HDMI到底怎么测的测试工程师，都可以往下读。内容会从测试环境的搭建讲到DDR训练日志的解读，再讲到HDMI信号完整性的抓取方法，最后整理一份我遇到过的故障速查表，全程用我自己的实操案例说话，不写教科书废话。

1. 测试开始前，先把平台和工具备齐

1.1 硬件平台的选择：是买核心板还是自己画测试板

H618的封装是BGA，个人或者小团队想直接在主板上飞线测DDR基本不现实，所以我会先把CPU做在一块小的核心板上，再通过板对板连接器引出DDR之外的所有信号。市面上现成的H618开发板，比如香橙派的Zero2W、Zero3这些，其实也是不错的测试载体，因为它们自带DDR，只要厂家没有把DDR的测试点完全阉割掉，你就能透过串口日志和压力工具验证DDR稳定性。

不过我个人的建议是：如果预算和时间允许，最好还是自己画一块只针对DDR和HDMI的测试小卡，原因有三个。第一，开发板的PCB走线是厂家调好的，你测出来的DDR各个参数都正常，不代表你自己画的板子也能正常；第二，开发板通常不会引出DDR数据线或地址线的测试点，你没法用示波器真正看到DQS和CLK的相对相位；第三，H618集成度高，很多电源域开发板已经做完了，你没法单独测试某个电源域对DDR训练的影响。

我自己实测用的是两层方案：先拿一块香橙派Zero3做软件调通和基本信号验证，确认系统能跑起来以后再画自己的四层测试板，把HDMI座、DDR颗粒、电源、串口全部按量产布局走一遍。这样即使后来自研板子出问题，也能对比开发板的行为来定位是自己的布线问题还是芯片设置问题。

1.2 软件环境：串口日志是DDR测试的第一双眼睛

硬件测试往往要配合软件才能把问题暴露出来。H618启动时，芯片内置的Boot ROM会初始化DDR，然后从SD卡、eMMC或者SPI Flash加载引导程序。只要DDR训练失败或者不稳定，系统会直接卡死或者反复重启，所以串口日志就是你判断DDR是否正常的最直接依据。

我的标准做法是这个：先用软件工具把Armbian或官方Linux固件写入TF卡，TF卡作为一个独立于DDR的启动介质，让系统先把DDR调起来，再跑到内核里看信息。这里需要注意一个细节，TF卡本身是通过SDIO接口访问的，和DDR完全独立，所以只要TF卡能启动并打印日志，基本说明CPU核心和PMU供电没问题；如果日志在DDR初始化阶段就断了，那问题多半出在DDR颗粒、DDR供电或者PCB走线上了。

H618串口默认的波特率很多固件是115200，调试串口引脚通常复用在某个UART上，具体看原理图。我习惯在固件里打开内核的早期打印，这样从Boot ROM到U-Boot再到Linux内核的所有输出都能抓到，方便定位是哪个阶段挂掉的。提一句，如果TF卡系统制作工具，像Rufus或者balenaEtcher，在Windows下写卡都比较省心，镜像写进去之后直接上电就能看到启动日志。

1.3 仪器准备：按照测试深度决定要花多少钱

硬件测试离不开仪器，但不是说每个人都要立刻配一堆高端设备。我给你按测试深度列一个参考表：

我自己实际配置是一台500MHz带宽、4GS/s采样率的示波器加一个1.5GHz的有源差分探头。坦白讲，500MHz带宽测HDMI 2.0的4K@60是有点不够的，因为TMDS时钟最高到600MHz，测眼图时高频分量会被示波器滤掉一些，但用来测1080P、判断信号有没有通、有没有明显反射，已经足够量级。真要验证4K@60的眼图，还是得找实验室或者借一台2GHz以上的示波器，这个后面会再展开说。

2. DDR部分：从原理到一次真实的排查过程

2.1 先明白H618内部怎么管理DDR

H618的DDR控制器集成在SoC内部，对外连接DDR3/DDR3L/DDR4/LPDDR4颗粒，具体支持哪几种以官方手册为准。控制器内部有一个PHY模块，PHY负责把控制器的逻辑信号转换成符合JEDEC规范的电气信号，同时做阻抗校准、ODT（片上端接）配置、读写训练等一堆事情。

DDR的工作频率高，信号在PCB上传输时会有延迟和反射，H618在启动时会对DDR PHY做“训练”，也就是不断调整读写数据的采样延迟、片内端接阻值、驱动强度等参数，去找一组让数据读写都稳定的配置。这个训练过程有的厂家叫“DRAM calibration”或“PHY training”，H618的日志里通常会有类似“DRAM PHY training”或者初始化DRAM控制器的打印。如果颗粒、走线或者电源有问题，训练就可能失败或者得到的参数裕量很小，之后系统跑起来就会随机死机、报错。

这个训练有点像两个人隔着一条走廊喊话：先试几次，找到对方能听清你的音量大小和应答延迟。如果你站的位置不对（信号反射）、走廊里很吵（电源噪声）、或者对方耳朵不好（颗粒质量问题），这个调参过程就失败，或者每一轮都得试很多次才成功，这种“勉强成功”其实是最危险的，因为上高低温之后必然翻车。

2.2 布线检查：等长规则和分组原则

在做任何电气测试之前，我会先用CAD工具（比如AD18，很多硬件发烧友都在用）把DDR相关走线过一遍，对照原理图和PCB报告严格检查。

DDR布线有几个硬规则，第一个是数据线分区等长。DDR的DQ、DQS、DM信号属于数据组，每组内部的走线长度差要尽量小，通常控制在几十mil以内，具体值取决于DDR频率。第二个是地址线、控制线、时钟线单独一个组，它们相对DQS/DQ有固定的等长关系。第三，DQS和CLK的差分对内等长要很小，因为DQS是数据采样的参考时钟，CLK是命令地址的参考时钟，两者偏差过大，训练时怎么调都找不准。

这里有个很常见的误区，就是只等长数据线而忽略了DQS到CLK的相位关系。我遇到过一块板子，DQ组内的走线长度很齐，但DQS整体比其他DQ短了快200mil，结果是DDR初始化偶尔能过，跑Memtester大概十分钟左右报一次错。后来我把DQS走线加了蛇形绕线调整到与DQ中值长度一致，问题才消失。说句实话，很多入门开发者不知道DDR走线等长不是“越短越好”而是“相对关系要稳定”，这个认知差异在调试时带来的痛苦是巨大的。

2.3 用Memtester和日志做第一轮稳定性验证

我每次拿到新的H618板子，上电后第一件事不是用示波器去抓波形，而是先确认系统能稳定启动并能跑内存压力测试。原因很简单：示波器只能看到某一个瞬间的信号，跑压力工具可能是更宏观的验证方式，能把DDR的“长期稳定性”这个指标暴露出来。

Memtester是Linux下的一个内存压力工具，使用很简单：

sudo memtester 512M 10

第一个参数是要测试的内存大小，第二个参数是循环次数。如果DDR初始化有隐患，Memtester通常会报出类似“FAILURE: 0xXXXXXXXX”的错误，告诉你具体的地址和数据。有时候系统直接死机或者重启，连错误都不打印，这时候就要靠看门狗和串口日志判断是不是DDR访问冲突导致的内核崩溃。

除了Memtester，我还会在内核启动后查看dmesg里关于DDR的信息，例如：

dmesg | grep -i dram

日志里能看到DDR频率、容量、数据位宽、颗粒类型这些关键信息，我见过不少板子因为固件里DDR类型选错，导致系统不稳定。比如本来是DDR4颗粒，固件却按DDR3的参数去初始化，多半会在启动早期就卡死。

压力测试的时长怎么定？我通常先跑5轮快速验证，没问题以后挂机过夜跑至少8小时。如果是为了高低温测试，则要在高低温箱里让温度稳定后跑2小时以上，因为DDR在临界温度下最容易暴露访问时序问题。

2.4 示波器抓DDR信号：怎么看核心波形

当软件压力测试出现不稳定，且能排除颗粒本身的问题后，就该请出示波器了。DDR的信号不是像I2C那样一个个孤立的波形，而是持续高速切换的总线，直接用普通探头去扎数据线的通断意义不大，你需要关注几个关键点。

首先是DQS和CLK的时序关系。H618的DDR控制器在读操作时，DQS是颗粒端输出的数据选通信号，处理器要依靠DQS边沿来采样DQ数据，所以DQS与DQ之间的时序必须满足建立保持时间。用示波器可以捕捉任意一条DQ和对应DQS的波形，观察DQ跳变沿距离DQS边沿的距离是否满足颗粒规格。在低速模式下你甚至可以清楚看到眼图开口比较大；如果开口小、边沿抖动大，那说明走线等长没控好或者串扰严重。

其次是电压和纹波。DDR的VDDQ电压通常由PMU提供，若纹波过大，会让颗粒内部的比较器误判电平。我用示波器探棒配合弹簧地针测量VDDQ时，发现纹波超过50mV，后续在DDR供电端并了几个去耦电容并把电源走线加宽后才压下去。这个细节很多人不在意，可我测过的DDR不稳定案例里，大概有三成是电源纹波惹的祸。

看DDR波形时还要注意一点，示波器探头必须是短地线，最好用探头自带的短弹簧针，因为你如果直接用长地线鳄鱼夹，接地回路电感会很大，测出来的波形抖动会骗你做出错误判断。这个坑我踩得最狠的一次，是测出DQS抖动高达300ps，后来换短地线再测不到80ps，原来那300ps全是测量系统引入的。

DDR部分我再分享一个排查案例，非常典型。有一块板子在高温老化时频繁重启，拆开看日志停在PHY训练失败上，常温却一切正常。我先怀疑是DDR颗粒虚焊，用X-Ray检查没发现问题；然后用热风枪给颗粒局部加热，大概到90度左右就复现问题了，说明问题在温度相关参数上。再看PMU的DDR供电电压，常温26mV纹波，高温箱里纹波上升到80mV，原来是电源模块的补偿环路在高温下不稳定了，加了对地电容后，高温下纹波压到45mV，老化测试顺利通过。所以遇到DDR和温度有关的问题，别急着怀疑CPU或颗粒，先去抓住电源纹波。

3. HDMI部分：接口定义、电路检查和信号抓取

3.1 H618的HDMI接口到底有哪些信号

HDMI接口看起来是一个扁平的19针座子，信号种类其实不少，但对于硬件测试来说，我们只关心直接影响出图、识别和稳定性的几条通路。项目热词里有人搜“HDMI接口信号定义”，这里我就把H618上常见的HDMI相关信号好好拆一下。

第一是TMDS数据通道，HDMI有3对数据差分线和1对时钟差分线，分别叫Data0+/-、Data1+/-、Data2+/-、Clock+/-，这是高清信号的主干道。H618内置HDMI TX，直接输出TMDS差分信号，连接到HDMI座子时要求差分阻抗100Ω。第二是DDC通道，即I2C总线（SCL、SDA），用来读取显示器或电视的EDID信息。没有EDID，发送端就不会知道对面支持什么分辨率，所以DDC不通，画面大概率不会正常输出。第三是HPD（Hot Plug Detect）热插拔检测线，电视机通过拉高HPD告诉发送端“我准备好了”，发送端检测到这个上升沿后会重新读EDID并执行HDMI握手。第四是5V电源线，HDMI座子的19脚会输出5V给下游设备供电，虽然电流不大，但短路风险很高。

还有一个经常被忽略的CEC，用来消费电子控制，比如用一个电视遥控器控制盒子。H618一般有CEC引脚，实现的话要串到座子的13脚。CEC不是出图必须的，但做量产整机时经常被要求验证。

3.2 静态电路检查：用万用表先摸一遍

上电之前，我会习惯性先用万用表测一遍HDMI相关线路的对地阻抗，防止焊接短路或者空焊。重点测这几个点：5V电源脚对地不能短路，TMDS差分对的每一端对地电阻应该一致（因为内部有端接阻抗），HPD脚对地看有没有上拉电阻。HDMI座子内部有外壳地引脚，这些要确保和主板地可靠连接，否则ESD防护和电磁兼容都会出问题。

很多人做HDMI接口电路设计时只在数据线上放ESD保护阵列，却忘了HPD和DDC信号也要做相应的保护。HDMI座子拔插频繁，静电打进来的概率很高，我见过不止一次因为HPD线上没有保护导致芯片内部被静电打坏的情况。常见做法是用一颗带ESD防护的HDMI保芯片，比如TI的TPD12S015这类，集成DDC电平转换、HPD缓冲和ESD防护一体，对H618这种集成方案来说，外围电路能省不少事，可靠性也更好。

3.3 上电联调：从HPD和EDID说起

很多HDMI无输出的问题，根源不在高速信号上，而是在低速的“握手”环节。如果你发现接上电视后H618没有任何显示输出，先别急着抓眼图，先用示波器探针测量HDMI座子19脚的5V是否正常，再测HPD脚有没有从低变高的跳变。

这里有一个很关键的顺序：HPD的上升沿是在5V电源稳定之后由电视侧拉高的。如果你测到HPD一直是低，那可能是电视不识别、HDMI线有问题，也可能是你的HPD被下拉电阻拉死了。我测过一块板子，HPD设计时漏了串联电阻，芯片内部下拉和电视上拉分压之后，电视拉高到不了逻辑高电平，芯片一直认为没接显示器，自然没有输出。加上一颗上拉电阻之后问题马上解决。

EDID的验证也很容易操作。如果系统能开机，在Linux下用i2c-tools就能读：

i2cdetect -l i2cdetect -y -r 0x50 i2cdump -y 0x50

HDMI的EDID挂在DDC总线上，地址一般是0x50，如果i2cdetect能扫到0x50地址，说明DDC通；再用i2cdump把EDID内容dump出来，能看清厂商、分辨率支持列表、色彩空间这些关键信息。我之前有一块板子在电视上能正常显示，但在某款显示器上只能到1080P，一开4K就黑屏，最后dum出EDID发现显示器的EDID里面写的最大TMDS时钟被识别有误，其实是DDC总线上的上拉电阻阻值太大导致时序畸变，把EDID数据读错了。换掉电阻后问题消失。

HPD和EDID都正常，内核日志里一般会打印类似“hdmi: detected monitor”或者DRM相关的连接状态变化。H618的Linux内核通过DRM/KMS框架管理HDMI输出，查看：

cat /sys/class/drm/card0-HDMI-A-1/status

如果返回“connected”说明热插拔检测成功了，再强制指定分辨率测试输出：

xrandr --output HDMI-1 --mode 1920x1080

这种方式可以快速判断是握手问题还是信号质量问题。

3.4 用示波器抓TMDS：眼图和摆幅的判断

HDMI的TMDS信号是电流驱动型差分信号，规范里单端摆幅一般在400mV到600mV左右，差分摆幅在800mV到1200mV左右，实际数值会因为驱动设置和线缆损耗有所不同。测TMDS眼图时，我会把示波器设成差分模式，用差分探头去夹HDMI座子附近的测试点，观察信号的眼图是否张开、上升沿是否单调、有没有因为插座或ESD器件引起的严重反射。

这里要说一句：测眼图要区分测试点位置。如果你在HDMI座子引脚上测，看到的是信号经过PCB走线后的波形；如果在同一根线接近SoC引脚的位置测，波形会更“干净”一些。我们做硬件测试，通常以座子附近为准，因为这才是下游线材真正会收到的信号质量。示波器带宽至少是信号最高频率的3到5倍，测4K@60的TMDS信号，600MHz的基频意味着你至少需要1.5GHz到3GHz带宽的示波器，否则测出来眼图会“假闭眼”，看起来信号很差，其实是示波器带宽不够。

实际情况下，如果测1080P信号，500MHz示波器配合高带宽差分探头完全够用，眼图打开得很明显。如果是4K@60，我通常退一步，测它的时钟通道以及数据通道的抖动，再用软件压力测试和实际显示器来验证，毕竟消费级实验室里能有2GHz示波器的地方还是少数。

CEC验证的话，用逻辑分析仪抓CEC引脚上的电平变化，确认遥控器按键事件能转换成CEC帧，这个相对独立，原理像UART单总线，波特率约3600bps。如果H618固件把这部分功能屏蔽了，你测CEC引脚可能是空的，这要根据项目需求决定要不要深挖。

4. 整机可靠性测试与常见故障速查

4.1 高低温、老化、ESD：硬件测试的最后一道关

DDR和HDMI单独测完，只能说明设计原理上没问题，真正决定能否量产的是整机可靠性测试。我的习惯是把DDR压力测试和HDMI视频输出同时放在高低温箱里跑，因为H618芯片本身发热量大，整机在高温环境里如果散热不够，DDR颗粒贴着CPU，温度会更高，内存稳定性会更严峻。低温则容易暴露晶振起振和电源启动的问题。

具体做法是这样的：高温60度、低温-20度各跑至少4小时，高温阶段跑Memtester加循环播放4K视频，低温阶段重点观察冷启动时DDR初始化是否成功、HDMI的HPD检测是否正常。温度循环不要直接满载到关机，H618这种BGA封装芯片温度剧变容易造成焊点应力损伤，测试完还要重新跑一遍常温全套功能，确保没有因为温度变化产生新的不良。

ESD测试是HDMI接口的常客，因为HDMI座子裸露在机身上。按照消费类电子的普遍测试要求，接触放电至少正负8kV，空气放电15kV，实验过程中不允许出现死机或者HDMI功能永久损坏。我见过一款产品HDMI插座没有做外壳接地隔离，打空气放电时静电直接耦合到TMDS线上，把SoC的HDMI TX烧了。后来在HDMI座子外壳和主地之间加了一颗高压电容，同时增加ESD保护器件，才顺利通过测试。这个细节在电路设计阶段就要规划好，测试阶段再补救非常痛苦。

4.2 常见故障速查表

我在H618项目里把遇到过的DDR和HDMI问题整理成了一个速查表，直接照着排查可以省很多时间：

这个表不是万能的，但覆盖了我在H618上遇到的大部分问题。硬件测试就是这样，现象往往很简单，背后的原因却是多层的，稳扎稳打一层层排除，比瞎猜要高效得多。

4.3 延伸一点：DDR和HDMI测试思路在其他平台同样通用

有人可能觉得H618太小众，这门手艺换一颗芯片就没用了。其实不是。DDR的PHY训练、等长布线、压力测试这套方法论，放在Zynq这类FPGA平台上一样适用，只不过FPGA上你可以用IP自带仿真工具先验证，实际硬件测试还是要回到信号和时序的测量上来。HDMI的HPD、DDC、EDID、TMDS这套流程，在RK3568、RK3576这些国产SoC上也完全一致，我见过很多RK平台HDMI适配问题，最后查出来都是硬件信号层面的HPD或者EDID不稳定，而不是驱动配置问题。

说句大实话，很多搞Linux驱动的人觉得HDMI“适配”是软件问题，但其实我在调RK3576 Android 14遇到插上HDMI线就没媒体声音的问题时，最后定位到是硬件音频路由和HDMI音频数据包的默认设置冲突，这种问题如果不回过去验证硬件信号，光在软件里调来调去会浪费大量时间。所以在嵌入式硬件这个行当，懂一点测试，能抓一下信号，很多时候比看十篇驱动移植教程更能解决问题。

另外像笔记本HDMI无输出这种常见的用户侧故障，原理上也逃不开HPD、DDC、电源这几条线，排查思路和测H618完全一样，掌握了本文这套方法，你甚至可以帮朋友修电脑时多一个思路。

最后说一点个人体会。硬件测试做久了，你会发现真正难的不是会用示波器，而是知道该测哪里、测什么参数、什么时候该相信测量结果。H618的DDR和HDMI测试，表面上是两条独立的技术线，实际都指向同一个核心：理解信号在PCB上的传输过程，理解芯片内部的握手逻辑，然后用尽可能简单的方式验证它们的边际条件。

我的经验是，测试用例要在设计图阶段就开始规划，比如预留DDR的等长测试点，把HDMI差分信号在座子附近预留可以下探针的焊盘，这些小事能让后面调试省一半力气。还有一个习惯就是每次测试都把示波器截图、串口日志、环境温度和当时的测试固件版本一起存档，因为自己调过的板子过几个月再回头看，你会发现这些记录比记忆可靠得多。