前几天我拿到一块基于NXP LX2160A的SoMSystem-on-Module评估板第一反应是这东西真不小整个模块比一张名片大不了多少但上面塞了16核Cortex-A72、双通道DDR4、4路SerDes还引出多个10GbE/25GbE高速接口。插上底板开机系统直接进入Linux运行iperf3打流25GbE端口轻轻松松跑满线速——整个过程让不少第一次接触Layerscape平台的朋友觉得“这也太顺利了”。但顺利背后是大量前面看不见的功夫。LX2160A作为NXP面向网络、边缘计算和企业存储市场的高端处理器它的启动过程、电源时序、SerDes协议配置、DPAA2软件栈适配每一步都比普通ARM平台复杂得多。这篇内容我按自己的实际经历来写从方案选型、硬件设计、软件部署到调试踩坑把整个SoM从无到有的过程拆开讲清楚希望能给准备用LX2160A或者类似Layerscape平台做产品的朋友提供一份可以直接参考的实践经验。1. 项目缘起为什么把LX2160A这颗16核处理器做成SoM1.1 LX2160A这颗芯片到底什么来头在聊SoM之前得先简单认识一下LX2160A。它是NXP Layerscape系列里的高端型号核心配置是16个ARM Cortex-A72核心最高主频2.2GHz采用16nm工艺。单看CPU架构可能觉得“不就是一堆A72嘛”但Layerscape系列的核心竞争力不在CPU算力而在那颗叫DPAA2Data Path Acceleration Architecture 2.0的网络加速引擎。DPAA2包含了WRIOPWire Rate IO Processor、QBMan队列管理器、Buffer管理器等组件可以做到让网络数据包绕过内核直接在硬件层面完成收发、解析、分类和转发。配合DPDK用户态驱动单核转发性能可以到线速实际跑起来比纯CPU软转发强太多。再加上LX2160A最多提供4个SerDes端口每个端口最多8条lane可以灵活组合出PCIe Gen3、10GbE、25GbE、40GbE甚至100GbE接口这让它特别适合做网络交换机、安全网关、边缘计算节点、白盒网络设备和企业级存储控制器。另外LX2160A支持完整的虚拟化特性ARM TrustZone、KVM、SR-IOV都没问题很多做边缘MEC和小型云节点的方案都是基于它。还有一点容易被忽略它集成了硬件加密引擎和支持ECC的DDR4控制器这对需要长期稳定运行、数据可靠性要求高的设备来说非常重要。1.2 SoM模式解决的真实痛点那问题来了芯片这么好为什么不直接拿来做核心板非要做成SoM我这里分享几个实际体会。第一是开发周期。LX2160A这类高端处理器硬件设计复杂度和普通MCU完全不是一个量级。DDR4 3200MT/s的布线需要精细的等长控制、阻抗匹配电源部分光是核心供电就要支持20多安培的电流上电时序、RCW配置、SerDes协议规划每个环节出错都可能导致启动失败。如果是第一次接触硬件方案从设计到调通顺利的话3到4个月不顺利半年以上都有可能。但直接采用SoM这些底层问题已经由模块厂商解决开发团队可以把精力放在底板功能设计和业务逻辑上硬件周期的缩短是肉眼可见的。第二是软件生态的继承。使用SoM意味着你拿到的是一个“可以启动的系统”ATF固件、U-Boot、Linux内核、DPDK驱动都已经调好基于它做应用开发完全是标准Linux流程。如果从零做核心板光是把DPAA2驱动和DPDK跑起来就需要大量调试而这些时间原本可以花在业务代码上。第三是迭代灵活性。做硬件产品最怕的就是核心板改版。改一版投板打样、焊接调试周期和费用都不低。SoM模式下底板设计相对简单改版成本低很多核心板如果有问题可以直接换模块不用动整个产品设计。当然SoM也有代价比如BOM成本会比自研核心板略高模块体积和散热设计也会受限制。但对大多数中小团队和做整机产品的公司来说用SoM换时间、换稳定性是非常划算的选择。1.3 目标场景与用户画像这个SoM项目针对的核心场景很明确我梳理了一下大致有三类第一类是网络设备制造商做企业级交换机、路由器、防火墙、负载均衡器的团队。这类产品对高速以太网接口、线速转发、虚拟化隔离和长生命周期供货都有苛刻要求LX2160A的DPAA2和丰富的SerDes能力正好匹配。第二类是边缘计算和MEC方案商需要在靠近用户侧部署计算节点既能跑虚拟机/容器又能做高性能数据面转发。LX2160A的16核CPU加上DPDK、SR-IOV支持可以在一台设备里同时承载业务应用和网络转发硬件成本和功耗都比“通用服务器网卡”的组合更有优势。第三类是工业与军工领域的控制与计算平台看重稳定供货、ECC内存、工业级温度范围以及安全启动等特性。SoM模块加自定义底板的方式可以快速满足这类项目对接口定制化和长期供货的要求。所以这个SoM的定位不是一颗单纯“跑分高”的ARM核心板而是一个面向网络密集型应用的完整基础平台。接下来我从硬件设计讲起把最核心的几个部分逐个拆开。2. 硬件方案解析电源、DDR与SerDes是三场硬仗2.1 电源树设计从多路供电到精密时序控制LX2160A的供电系统比普通嵌入式平台复杂得多我第一次看数据手册里那几十页电源要求时感觉像在看一个FPGA项目的电源预算。简单列一下核心供电VDD1.0V标称满负载电流在20A以上根据频率和负载不同变化DDR供电VDD 1.2V和VDDQ 1.2V电流和容量相关IO供电1.8V和3.3V若干组SerDes模拟供电AVDD1.0V对纹波和噪声要求很严各类辅助电源0.9V、1.5V等如果你打算自研LX2160A核心板第一步就是把这些电压需求整理成一张电源树表逐路标清楚电压、最大电流、纹波要求和上电时序关系。我见过不少初次设计的人在这里翻车最常见的问题是只算了CPU核心电流、没算DDR和其它接口的总功耗结果DCDC选小了跑个负载测试就掉电重启。关于上电时序LX2160A对电源轨的排序有明确要求通常需要遵循“先外围、后核心、最后DDR”的顺序不同轨之间还有最小时间间隔。这里我的建议是不要完全依赖PMIC的默认时序最好加一颗CPLD或者用MCU做专门的时序控制这样既能精确满足手册要求又方便调试时灵活调整。实际操作中还有个细节SerDes的模拟电源AVDD对电源纹波极其敏感纹波太大直接导致高速接口误码率上升甚至link不稳。因此AVDD这一路要使用低噪声LDO或者在后级加足够的磁珠和π型滤波不能直接拿DCDC输出怼上去。提示电源时序问题最典型的故障现象是模块上电后U-Boot都没有打印或者启动过程中DDR初始化失败。如果遇到这种情况先用示波器逐路抓上电波形对照手册确认时序比盲目调代码高效得多。2.2 DDR4布线3200MT/s的信号完整性实践LX2160A的DDR控制器性能很强支持DDR4 3200MT/s、双通道、ECC校验容量上限可以做到128GB。高速DDR布线是整个SoM设计里对硬件工程师要求最高的部分。在3200MT/s这个速率下信号的上升沿已经非常短布线不再是简单的“连上就行”必须考虑传输线效应、阻抗匹配、串扰和时序余量。我的经验是以下几件事必须做好第一叠层设计。SoM通常是6到8层板DDR走线需要专门的参考平面尽量做到连续、完整。建议DDR信号走在靠近参考平面的内层避免表层走线带来的电磁干扰。第二等长控制。同一组数据线、地址线、控制线都要做等长匹配DQS与DQ之间要做T型或Fly-by拓扑的时序补偿。具体等长公差建议参考芯片手册和控制器要求一般控制在±25mil以内比较稳妥。第三端接电阻。DDR4地址和控制信号需要VTT端接数据线如果控制器内置了片上端接ODT则通常不需要外部端接电阻这可以省不少面积。第四SPD EEPROM。虽然有些设计为了简化省掉了SPD但LX2160A的DDR控制器会自动读取SPD来做训练接上SPD能让初始化过程更可靠也方便调试时检查内存参数。I2C地址别搞错通常对应0x51或0x53。如果你们团队之前只做过MCU或者低速板卡第一次碰DDR4 3200MHz建议直接让SoM模块厂商提供完整参考设计或者购买标准的DDR4 SODIMM方案来降低风险。自己从零布线不是不行但调试DDR训练的过程真的非常痛苦稍有不慎就是各种随机死机、数据错误。2.3 SerDes Lane规划先把账算清楚再动工LX2160A的4个SerDes端口SerDes 1到SerDes 4每个端口最多支持8条lane全部是双向高速串行接口。这些lane可以在RCWReset Configuration Word里配置成不同的协议组合比如PCIe、SGMII、10GbE、25GbE、40GbE、100GbE、SATA等等。这里说的“配置”不是软件驱动层的配置而是芯片上电复位时读取RCW来确定的硬件行为。RCW里会写清楚每个SerDes端口的协议模式以及每一条lane的用途一旦配置错了后面的驱动再怎么折腾也无济于事。因此做SoM方案设计的第一步是把所有需要用到的高速接口列一张总表算清楚每条lane的归属。比如一个典型的应用场景需要2路25GbE每路需要1个SerDes lane共2条lane1个PCIe Gen3 x4插槽需要4条lane1个PCIe Gen3 x2 NVMe接口需要2条lane2路SATA 3.0每路需要1个SerDes lane共2条lane这样一算总共需要242210条laneLX2160A总共提供32条lane看起来绰绰有余。但实际还要考虑端口分组的限制比如某些SerDes端口只能配置成以太网协议某些lane组合不能跨端口随意使用。我建议早早在RCW参考文档里把想要的协议组合查清楚再用NXP提供的RCW生成工具或者官方Example逐个验证不要靠猜。这里有个很容易踩的坑SerDes不同协议对参考时钟频率的要求不一样PCIe Gen3需要100MHz参考时钟25GbE需要156.25MHz或者161.1328125MHzSATA需要150MHz。如果SoM上所有SerDes共享同一个参考时钟源就必须用可编程时钟芯片按RCW配置输出对应频率或者在硬件设计时预留多路时钟选择电路。这个细节如果没提前规划好后面调试网络/PCIe不稳定时会非常头疼。3. 软件部署从RCW一键启动到DPDK线速转发3.1 RCW与U-Boot芯片出生那一刻起的关键硬件设计再扎实软件起不来也是白搭。LX2160A的软件启动链比普通ARM平台多了一个RCW的环节。RCW本质上是一段在芯片复位时加载的配置字存放于QSPI NOR Flash、I2C EEPROM或SD/eMMC等启动设备中。处理器上电后会先读取RCW根据RCW里的内容确定SerDes协议、核心频率、DDR频率、U-Boot的加载地址等一系列参数。所以严格来说RCW才是LX2160A的“第一段代码”。RCW的生成一般使用NXP官方的配置工具里面有很多预设模板。你只需要把SerDes协议号、时钟频率等参数填进去工具就会生成最终的二进制或者文本格式RCW文件。然后通过烧录工具写入启动Flash之后每次上电芯片都会按照这个RCW初始化。U-Boot方面NXP的LSDKLayerscape SDK里直接提供了适配LX2160A的U-Boot编译流程比较简单。但有几个常见问题我得提醒一下首先是环境变量。LX2160A的U-Boot默认从“fdt_addr0x...”这样的地址加载设备树如果从SD卡启动要确认bootcmd里的设备号、分区、内核镜像路径都正确。有个朋友第一次启动时一直卡在内核解压后来发现是U-Boot没把设备树传到正确地址。其次是内存初始化。U-Boot启动时会做DDR控制器配置和训练如果硬件上的DDR颗粒与RCW/DDR工具配置的参数不一致比如时序参数比实际颗粒慢或者Rank数不对会在U-Boot阶段直接报错或者死循环。这里建议使用NXP官方的DDR调试工具来生成匹配的DDR初始化参数不要手动瞎改。另外LX2160A支持从多种介质启动常见的是QSPI NOR Flash和SD卡。开发阶段用SD卡启动非常方便改代码直接换卡就行量产阶段则建议固化到QSPI NOR或者eMMC防止SD卡松动导致启动失败。3.2 ATF、内核与设备树让DPAA2真正跑起来U-Boot之后是ATFARM Trusted Firmware它负责切换EL3到EL2/EL1然后跳转Linux内核。LSDK已经把这部分串好了通常不需要单独改动ATF源码除非你要定制安全启动或者可信固件功能。内核方面LSDK基于较新的稳定版内核打了一堆DPAA2驱动补丁还提供了对应的内核配置文件。直接使用官方内核配置编译是最省力的方式个人不建议自己在标准内核上从零配DPAA2那会遇到非常多的驱动依赖问题。设备树是LX2160A软件适配里的重头戏。LSDK默认设备树已经覆盖了大多数外设但你要根据自己SoM的SerDes配置裁剪和修改。举个例子如果你在RCW里把某些lane配成了2路25GbE就需要在设备树的fman/eth节点中使能对应的接口并设置正确的PHY模式。如果设备树里节点没匹配上网卡根本不会注册出来内核启动日志里也只是一行bare的“不支持的设备”信息靠日志定位起来很费劲。DPAA2架构下网络接口的管理方式也不同于普通网卡。它不直接生成eth0/eth1而是通过restool工具创建DPNIDPAA2 Network Interface对象再绑定成网络设备。初次接触这个流程的人会觉得“怎么这么绕”但理解了它“硬件对象化管理”的思路后会发现这对虚拟化和多租户场景非常友好。我的建议是先把LSDK文档中关于DPAA2的快速入门章节完整读一遍重点理解“DPRC-DPNI-DPMAC”这几个对象层次然后按文档步骤用restool创建接口并测试。等跑通了再考虑怎么和DPDK、容器网络插件对接。注意LX2160A的Linux内核配置建议只在官方LSDK基础上做增量修改不要试图精简掉DPAA2相关配置。这些驱动之间关联很深少一个依赖就可能导致整个数据面起不来。3.3 网络性能验证iperf和DPDK的实测结果软件环境搭好之后第一件事不是急着写业务代码而是验证网络性能确认底层数据面是通的、速率是达标的。我习惯先用常规TCP/UDP打流工具做初步验证。在LX2160A上启用两个25GbE接口分别跑iperf3双向各4个并发流单接口打满线速25Gbps是正常表现。这里有一个需要注意的点默认情况下的吞吐量可能会受CPU中断处理能力影响尤其是多队列中断没有正确分配到不同核上的时候。你可以用smp_affinity把网卡中断绑定到不同的CPU核心上或者在内核启动参数里加上isolcpus把某些核隔离出来专门处理网络中断。真正要发挥LX2160A的数据面性能肯定绕不开DPDK。LSDK提供了DPAA2的DPDK PMD驱动编译好DPDK后再用testpmd或者l3fwd示例做验证。我实测一个典型场景16核全编译用l3fwd跑2路25GbE双向转发单核处理速率大约在19到20Mpps满足大多数非超高密度转发场景的需求。如果把DPDK的PMD线程绑核、优化内存池配置还可以再往上挤10%左右。用DPDK做业务时需要注意内存池大小、MBUF数量、队列数和CPU绑核配置。太小的内存池会导致丢包太大则浪费内存。以2路25GbE为例我一般配置每个接口4个RX队列、4个TX队列MBUF数量配到1万以上再配合CPU绑核工具把PMD线程绑到固定的四个核心上这样可以做到零丢包转发。做性能对比时我看到很多团队只测单方向、单流这实际掩盖了问题。建议把双向、多流、不同包长64字节小包、128字节、512字节、1518字节大包都测一遍才能在项目早期发现瓶颈所在。4. 调试实录那些让开发崩溃的问题与解法4.1 启动阶段电源时序和DDR训练的经典坑这个部分是我最想写的因为实际项目里80%的时间都在和这些“低级但致命”的问题搏斗。先讲电源时序。有一版SoM在原型调试时频繁出现偶发性启动失败用示波器抓波形后发现核心电压和DDR电压之间有个几百微秒的交叠不符合手册要求。因为在低温环境下PMIC之间的使能信号延时偏大导致时序裕量不够。后来在CPLD里加了一级状态机对每路电源的PGPower Good信号做判断下一路必须在上一路PG有效后再延时启动问题才彻底解决。所以别迷信PMIC的时序控制独立CPLD做时序在高端SoM设计里几乎是必选项。然后是DDR训练失败。表现是U-Boot启动日志打印到DDR初始化就卡住或者偶尔能启动但运行一段时间后随机崩溃。排查手段是查看Qixis FPGALX2160A平台上的硬件管理器件的寄存器状态再结合串口打印的DDR训练错误码定位。我们遇到过两种原因一是RCW里配置的DDR频率高于内存颗粒实际能支持的频率二是SPD EEPROM里没有正确写入内存参数导致控制器训练时使用了错误的时序。解决办法很简单把DDR频率降到颗粒规格书允许的范围确保SPD内容正确问题就解了。还有个之前不提但确实存在的情况DDR训练和温度有微妙关系。冷启动时训练失败热启动却正常这种随机现象多半是电源纹波在高低温下变化导致信号余量不足优先检查DDR的VDD/VDDQ纹波以及参考电压VREF的滤波电路。4.2 外设不通SerDes协议错配怎么定位SerDes相关的问题连NXP FAE都会问你第一句话“RCW里的SerDes协议是多少”。如果你答不上来基本就只能大海捞针了。我在调试过程中遇到过一个典型案例按原理图设计把SerDes 3的一条lane配置成了SGMII用于连接底板PHY但启动后Linux看不到这个网口。先检查RCW发现协议号配置成了某个只支持PCIe的组合SGMII那条lane被初始化成了未使用状态。重新生成RCW把SerDes 3配置成正确的协议后网口就正常出现了。另一个高频问题SerDes链路起来后不稳定表现为偶尔断链、误码增加。排查时先把链路速率固定下来例如强制25GbE不自动协商看问题是否缓解如果依旧则要检查参考时钟质量。我们实测过参考时钟抖动偏大时25GbE链路的误码率会明显上升。解决办法是选择低相噪的时钟芯片并在时钟输出端加足够的滤波电容。PCIe设备枚举不到也是常见问题。当RCW里配置了PCIe但实际上电后没有设备时先确认RCW里的协议号和lane分配再确认PCIe参考时钟是否在复位前稳定。用lspci看看总线上有没有设备在U-Boot里用pci enum命令也可以快速判断是硬件问题还是内核驱动问题。这些排查步骤的通用思路是首先确认RCW和硬件设计一致然后借助U-Boot阶段的基础测试工具去验证最后再进入操作系统驱动层排查。不要一上来就怀疑内核驱动很多时候问题在更底层的初始化环节。4.3 工具链与开发环境NXP生态的共性经验聊到NXP的调试工具链可能很多做MCU的人更熟悉SDK和IDE比如S32 Design Studio。我记得有段时间在调S32K344的bootloader当时S32DS的调试器startup设置没配对程序一跑就飞折腾了很久才发现是调试器复位类型配置不对。这类问题和LX2160A的RCW问题逻辑上很像——都是初始配置没对上硬件实际状态。NXP从MCU到MPU的开发工具链差异很大但共同经验是官方SDK和示例代码是第一优先级参考。比如很多人在S32K118上做底层配置直接拿NXP SDK的初始化代码改比从寄存器手册一个个查要快得多。到了Layerscape平台也一样LSDK里的U-Boot、内核、restool、DPDK示例都是多年沉淀的稳定版本不要轻易替换成社区最新内核。还有一次我同事在跑某个Java驱动的可视化数据映射工具时遇到“mapping processor内部空指针异常”的问题查了半天最后发现是JDK版本太高导致工具不兼容。这类开发环境问题不是NXP独有但提醒我一个道理大量嵌入式开发工具对运行环境的版本有严格要求建议在项目文档里固定工具链版本号避免团队成员各用各的版本导致问题相互踩踏。关于RT1176顺便提一句这颗i.MX RT系列跨界MCU在工业HMI和智能家电上用量一直很大很多方案商直接拿官方SDK改。它和LX2160A的使用逻辑很像先完全信任官方参考设计再根据自己的PCB和外设修改。官方SDK里的东西永远比你自己从零开始要稳得多。5. 产品落地载板、散热与选型对比5.1 载板设计的几条硬规矩SoM不是终点它要插到载板上才能成为真正的产品。载板设计相对简单但有几个地方不能忽略。第一是连接器选型。LX2160A SoM一般通过板对板连接器与载板连接高速SerDes信号必须选用支持对应速率的连接器例如PCIe Gen3和25GbE信号推荐使用高速差分连接器并严格按连接器厂商的推荐焊盘和参考地平面设计。有些载板为了省成本用普通连接器传25GbE信号结果是信号完整性完全不达标链路根本起不来。第二是电源和地的规划。虽然SoM已经集成了主要供电但载板上的PHY、时钟、电平转换等器件也需要良好的去耦设计。电源层和地层要尽量完整避免在高速信号下方被电源平面分割。如果有多个25GbE接口注意PHY的电源滤波防止PHY的开关噪声串扰到SerDes信号。第三是测试点预留。在载板上预留串口、JTAG、电源测试点、高速信号测试座是非常有价值的设计。很多问题在带壳组装后很难复现提前预留测试点会让调试方便非常多。我见过有团队连串口都没引出出了事只能靠着万分痛苦的焊线去救急这钱不值得省。5.2 散热与机械设计35W的账要算全LX2160A满负载工作时的功耗大约在35W左右这个热量在SoM这么小的体积内非常集中散热设计必须作为项目重点来做。很多人只计算了芯片本身的功耗却忽略了DDR4内存颗粒、网络PHY、电源转换效率等其它发热源最终整机温升远超预期。我做过一个25GbE防火墙的散热测试环境温度45°C下SoM的CPU核心用被动散热器加系统风扇导热垫选用2W/mK以上的材料实测温度稳定在85°C以内这个结果是可以接受的。如果采用的是被动散热无风扇方案那就要对CPU频率做限制或者选低功耗的型号比如LX2162A主频2.0GHz以便在功耗和性能之间取得平衡。机械设计上要注意SoM和载板组合安装时的支撑结构。SoM重量虽然不大但加上散热器后重心会升高如果只有板边固定在振动环境中容易出现连接器松动。建议在散热器下方增加支撑柱或者在载板上设计固定孔把散热器直接固定在机箱结构件上。5.3 与NXP其他平台怎么选一张表看清定位NXP的产品线非常长从低功耗跨界MCU到高性能Layerscape处理器都有覆盖。不少人问过我“到底选RT1176、i.MX 8M Plus、LS1028A还是LX2160A”下面这张表是我根据实际项目经验整理出来的选型参考平台核心配置典型应用场景网络能力开发难度RT1176单核/双核 Cortex-M7 M4工业HMI、智能家电、电机控制百兆/千兆以太网低i.MX 8M Plus4核/6核 Cortex-A53 NPU边缘AI盒子、视觉检测千兆以太网中LS1028A双核 Cortex-A72工业交换机、TSN网关2.5GbE TSN支持中高LX2160A16核 Cortex-A72企业交换机、边缘MEC、存储10GbE/25GbE/100GbE高制表时不少人会纠结i.MX系列和Layerscape系列的区别其实核心看两点是否需要DPAA2级的数据面加速能力以及是否需要25GbE以上的高速网络接口。i.MX 8M Plus虽然也有NPU适合AI边缘推理但它的网络能力停留在千兆级做不了高密度转发LX2160A则完全是为了数据面性能而生的非常适合网络密集型场景。RT1176“使用量多不多”这个问题其实反映出很多做工业产品的公司关注生态成熟度。RT1176的SDK、社区资料非常丰富用量大意味着踩坑概率低、技术风险小适合快速量产。但你要是做25GbE防火墙RT1176的性价比再高也无能为力必须上LX2160A这个级别。选型时还有一个现实问题CPU算力之外要提前确认外设接口是否够用。例如你要在边缘盒子里插4个PCIe设备同时还想做2路25GbE那就要计算Lane数量确认LX2160A能不能满足而不是买到手才发现资源不够。我自己在实际项目中最大的体会是LX2160A SoM这种平台真正难的从来不是某个孤立的技术点而是整个系统从RCW到DPDK的全链路贯通。硬件设计、RCW配置、设备树、DPDK驱动这四者必须完全对齐任何一环有偏差表现出的问题都可能五花八门、非常迷惑。再分享一个实用小技巧拿到LX2160A SoM后先别急着接底板做业务分别在U-Boot阶段和Linux阶段把每一项硬件功能都过一遍测试清单。U-Boot里可以测试DDR读写、PCIe枚举、网口link状态Linux里可以用restool查看DPRC/DPNI状态用ethtool看网口速率跑一遍完整的内存压力测试。这个基础验证流程走通了后面做业务开发会舒服很多。最后再提醒一次RCW和SerDes规划一定要在最开始就花时间弄明白。这个环节如果省事后面所有调试时间会加倍还回来。就这个坑值得所有做Layerscape平台的人提前记住。