1. 项目起飞把 88E6390X 跑在无 CPU 状态前阵子做了个项目单板上选了 Marvell 88E6390x 以太网交换芯片。按惯性思维第一步就是把管理 CPU 画上去跑 Linux然后从 SMI 口初始化芯片。可后来方案评审的时候仔细算了一笔账这个产品的功能非常固定24 口千兆加 4 口万兆二层线速转发不需要动态路由也不需要用户登录设备去敲命令。于是团队改成了 No-CPU 模式——不挂管理 CPU只挂一颗 EEPROM把需要初始化的寄存器配置做成镜像烧录进去。芯片上电后自己加载自己初始化然后直接进入转发状态。这篇文章我就把 No-CPU 模式下配置与烧录的完整实操过程讲清楚如何设计配置镜像、如何烧录、如何验证、以及最容易踩的坑在哪里。内容默认你已经看过 88E6390X 的硬件手册具备基础知识但不需要提前跑过完整 SDK。我尽量把每个决定背后的理由也写出来这样你遇到和我不同的硬件环境时也能自己推演该怎么改。1.1 No-CPU 模式到底图什么先解释一下这里说的 No-CPU 模式指什么。传统做法里交换芯片就像一台没有操作系统的“裸机”转发引擎它本身有很强的转发逻辑但端口怎么分组、VLAN 怎么划分、哪些帧可以上送管理口这些行为必须由外部实体写入寄存器。外部实体通常是 CPU。No-CPU 模式就是把 CPU 干的那件事挪到了 EEPROM。具体流程复位释放之后交换芯片根据 strap pin 判断启动源主动从 EEPROM 读取一段字节流字节流内部包含寄存器地址和期望写入值芯片把这些值依次写入自己的寄存器空间完成 PHY、SerDes、端口、VLAN 的初始化。整个过程不需要主机介入系统起来后交换逻辑是自运行的所以也被一些人叫“无主机模式”“哑交换机模式”但哑只是表象内部该做什么还是做什么。从产品角度看收益非常明显省掉一颗 CPU、一组 DDR、一片 Flash还有这一大堆器件带来的电源网络。PCB 面积小一圈BOM 成本直接降下来功耗也跟着降。而且没有操作系统的调度延迟没有软件崩溃的风险系统启动时间从几十秒压缩到几百毫秒级别。对只需要固定转发行为的接入交换、工业交换、板内交换场景来说这是非常合适的设计取舍。1.2 这套玩法适合谁不适合谁没有一个方案是万能的。No-CPU 模式听起来节省但代价是把灵活性交给了“出厂前定死”。后期如果用户想增加端口 VLAN、改镜像口、加 QoS没有控制面就等于改硬件配置必须返厂改 EEPROM或者留一个调试口等待现场工具升级。这就决定了它有明显的适用范围。我自己的判断标准是这样如果产品只做固定二层转发VLAN 划分基本不变端口速率和模式也都是硬件初始化就能确定的那就适合 No-CPU。如果产品计划支持动态路由、RADIUS、CLI 配置、远程管理、频繁版本升级那趁早老老实实上管理 CPU。还有一类情况不建议强行无 CPU——同时要做很多种复杂业务叠加比如 ACL 规则几百条、PTP 跨 VLAN 转发这类业务只靠寄存器初始化很难覆盖完整还是交给 CPU 跑协议栈更靠谱。从开发速度上讲带 CPU 的方案在早期可以用 SDK 快速调通功能No-CPU 模式则需要把功能拆成一个一个寄存器写操作前期的调试强度确实更大。所以团队如果第一次碰 88E6390X我建议不要一上来就追求全套 No-CPU先把“拿 CPU 调通链路”作为第一步再逐步把寄存器配置固化下来。这也是我们实际项目里采用的路径后面我会沿着这个思路讲配置清单怎么整理。1.3 一个起点从默认二层交换走向定制转发Marvell 交换芯片上电后如果没有 EEPROM或者 EEPROM 无效通常会进入一组默认值。很多芯片在这种状态下也能转发但行为是“最朴素的二层交换”所有端口默认加入一个 VLAN地址学习开起来帧进来以后按 MAC 表转发。如果你的板子只需要这种行为其实不加任何配置都能工作。然而实际项目哪可能这么简单。以我们这块板子为例4 个 10G 上联口要和千兆接入口分开 VLAN接入口还要分成多个隔离组每个组之间不能互访。这些需求统统要写配置。所以从默认状态到目标行为中间所有寄存器变化就是我们要固化的内容这也是后面配置镜像设计的起点。把这一层想明白No-CPU 模式就没有什么神秘的。2. 硬件摸底端口规划、启动引脚与最小系统检查2.1 端口资源和 SerDes 复用要在一开始就定死88E6390X 是集成度比较高的交换芯片常见形态是十来个 SerDes有些配置成 10G有些配置成 SGMII/1000Base-X再通过外置 PHY 转成电口。因为它不是“一个端口绑死一种速率”的简单结构而是同一路 SerDes 有多个复用协议所以硬件设计阶段就要把每一路 SerDes 的用途确定下来。以我的项目为例当时把 0-3 号 SerDes 设成 10G 上行接光模块4-9 号 SerDes 用作 SGMII10-23 号的千兆端口则走了 RGMII/SGMII 到外置 PHY。这个映射表直接决定了后面 EEPROM 里端口寄存器怎么填。千万别指望芯片灵活到自动识别你要用 SGMII 还是 10GMarvell 的 SerDes 配置在大多数情况下需要明确写寄存器写入错了后面链路直接起不来。还有一点要提醒No-CPU 模式不会帮你协商外部 PHY 的存在。如果某一路 SerDes 连接的是 SFP 模块而你写的是 1000Base-X模块插 10G 光模块上层就可能协商异常。最佳实践是先看硬件原理图把 MAC 侧期望的速率列表整理出来再结合业务需求确定最终固定值最后才去翻寄存器手册找对应位。2.2 启动链路strap、EEPROM、SMI 三者如何配合光有交换芯片和 EEPROM 还不够芯片得先知道从哪里读配置。这里扮演决策者的就是 strap pin也就是芯片外围通过上下拉电阻固定的配置引脚。硬件上电的一瞬间芯片把这些 pin 的状态锁存下来决定后续行为包括“使能 EEPROM 启动”和“EEPROM 使用几字节地址”等。从调试视角看还有一根非常重要的管理总线 SMI物理层就是两条线MDC/MDIO。No-CPU 模式虽然不在运行时依赖 CPU但我们在研发阶段必须把 SMI 引到调试接口不然芯片起不来你都不知道发生了什么。用 SMI 可以直接读写交换寄存器把 EEPROM 里烧的值和实际生效的值做对比这是排除配置问题的关键手段。还有第三件事值得注意EEPROM 不一定非得用 I2C。Marvell 有些芯片会把接口配置成 SPI甚至并行接口。我这次用的是非常普通的 I2C EEPROM芯片功耗低布线也简单。至于你手上是哪一种还是那句老话数据手册的 strap 说明和 boot flow 章节是最终权威原理图上留好 0Ω 电阻给后续调整留一条活路。2.3 打样前最容易翻车的三个硬件细节第一复位电路。No-CPU 模式的启动时机非常依赖复位释放后的时序。如果复位信号上拉太弱芯片可能在电源还未稳定时提前释放EEPROM 初始化就会失败。建议复位脚加 RC 延时调试时最好能手动复位。我自己习惯在板上加一个轻触按键别看它土调启动问题的时候不知道能省多少事。第二时钟。88E6390X 这类交换芯片对参考时钟的抖动有要求现场为了便宜选了个温漂大的晶体SerDes 误码率会很头疼。时钟问题不像代码问题那么直观有时候同样的寄存器配置这块板稳定那块板偶发丢包查了一圈发现是时钟的问题。时钟源选好之后不要在时钟线上绕太多弯更不要让高频信号贴着走。第三EEPROM 的 I2C 地址和 SMI 地址冲突。板上一堆器件各占各的地址I2C 设备如果地址没选对EEPROM 启动时读回来的全是 0xFF相当于没配。这个问题排查起来很容易慌因为上电时看不到错误日志。我的做法是在硬件调试阶段把 I2C 总线单独拉出来用逻辑分析仪看一次波形就能确认芯片到底有没有发起读取。3. 配置清单设计把初始化流程变成可反复烧录的镜像3.1 先读清楚寄存器依赖再谈写配置很多人第一次做 No-CPU 配置容易按“从前到后把寄存器抄一遍”的思路从 0x0000 一直写到 0xFFFF。这是最差的方案。一方面太多无效写入会浪费时间上电启动时若有超时限制可能会写不完另一方面交换芯片寄存器不是所有值都能随便写很多位域有依赖关系必须先配置基础功能再配高级功能。典型的依赖例子SerDes 协议选择寄存器往往依赖电源和 PLL 已稳定端口速率和双工模式依赖 SerDes 模式已经设对VLAN 表建立依赖端口编号和端口使能已经生效。所以配置顺序应该按“底层到高层”时钟/PLL → SerDes/PHY → MAC/端口使能 → VLAN/转发表 → 辅助功能。在生成 EEPROM 镜像之前我建议先用带 CPU 的临时板跑一遍 Marvell SDK或者直接在调试主机上通过 SMI 一条一条写寄存器把每一步记录下来。这样的记录比凭空看手册要靠谱得多它来自芯片的真实反馈还能观察中间是否有异常。如果是完全从零开始的新板子这个前期投入绝对不能省。3.2 端口、PHY 与 VLAN最小可运行配置长什么样以我做的固定功能交换机为例一份最小可运行配置至少包含三块内容。第一块是 SerDes/PHY 配置主要解决物理链路问题。包括每路 SerDes 的模式、速率、是否使能以及外部 PHY 的寄存器初始化。PHY 部分其实也可以有另一种做法就是把 PHY 配置写进 PHY 自己的 EEPROM用 PHY 的引脚配置自动加载。但为了统一管理我更倾向把所有内容集中在交换芯片外挂的 EEPROM 里由芯片初始化时统一下发避免两套镜像互相打架。第二块是端口配置解决“端口能不能转发”的问题。包括端口使能、收发包是否使能、端口默认 VLANPVID、端口模式是 access 还是 trunk 等。这里特别容易踩坑的是光使能了端口但端口没加到任何 VLAN 的成员列表里收进来的帧还是会被丢掉或者走默认规则互相串通。第三块是 VLAN 表。Marvell 交换芯片通常维护一张 VLAN 表每个 VLAN 表项里有本 VLAN 的成员端口。No-CPU 模式下如果没有外置 CPU给你动态建表就必须把需要的 VLAN 表项也写进 EEPROM。这一块在生成镜像时是最容易漏的我当时为了排查一个“VLAN 配置了依然通不了”的故障整整花了一天最后发现只是某个端口漏加了 member 位。配置块典型内容出错表现SerDes/PHY接口模式、速率、SFP/电口选择端口不亮、协商失败端口配置使能、PVID、端口模式帧收进来被丢弃VLAN 表成员端口、tag/untag同 VLAN 不通、跨 VLAN 互通3.3 镜像文件的组织方式和校验思路从 EEPROM 读到芯片的数据不是随便顺序堆在一起通常会有相对固定的组织格式。不同系列芯片、不同固件版本可能不一样但大体上会有三个要素引导头、地址数据列表、校验值。引导头标识这是一个合法的配置镜像地址数据列表给出每条要写入的寄存器地址和值校验值保证存储过程中不损坏。我在实际项目里写过一个生成镜像的 Python 脚本先把寄存器列表转成二进制再拼上头部和校验值。下面是一个简化版本只用来演示思路具体字段请以你的芯片手册里的 EEPROM boot 格式为准import struct import binascii entries [ # (寄存器地址, 写入值) (0x0001, 0x0080), (0x0002, 0x0001), (0x0010, 0x3000), ] body bytearray() for addr, val in entries: body struct.pack(HH, addr, val) crc binascii.crc32(body) 0xFFFFFFFF header b\xAA\x55 # 引导标记具体以手册为准 header struct.pack(H, len(entries)) image header body struct.pack(I, crc) with open(switch_eeprom.bin, wb) as f: f.write(image)这里有两个易错点。第一字节序。Marvell 寄存器字段用大端还是小端排列必须确认写反了虽然 CRC 可能没问题但寄存器值全部错乱。第二CRC 的种子和覆盖范围。有些芯片还会带地址掩码或者二次校验建议先用小实验镜像验证芯片确实能识别再批量生成正式镜像。4. 烧录实战从空片到满速转发4.1 烧录工具和最小准备动作EEPROM 烧录有两条路。一条是把 EEPROM 从板子上拆下来放到通用编程器上刷写适合量产或板子还没焊接的场合。另一条是直接在板子上烧用 I2C 总线连接 EEPROM在 Linux 主机上用 i2c-tools 往指定地址写。我这次量产前用编程器调试阶段用板载直写两条路都实测过。直接在板载烧录时最好把交换芯片和 EEPROM 的控制关系断开。最简单粗暴的办法是断电因为芯片没上电就不会去读 EEPROM此时 I2C 总线由烧录主机单独控制。如果是量产板还能用测试治具的 I2C 探针直接夹在 EEPROM 引脚上但要先把板上的 I2C 上拉电阻考虑清楚不要造成主机和芯片同时驱动总线。准备动作也很简单接好 USB 转 I2C 或直接用主机 I2C 控制器确认 EEPROM 的 I2C 地址。一般 I2C EEPROM 地址是 0x50 开头后面由地址引脚决定。这个地址可以在烧录前用 i2cdetect 扫一遍确认避免对着空气写半天。4.2 按地址写入并回读校验I2C EEPROM 有页写限制比如每页 32 字节或 64 字节跨页连续写会导致卷绕或丢失。所以写入时不能一股脑把整个文件丢给总线必须按页批量写每写一页等写入周期结束再写下一页。一个常见的可复用脚本形如#!/bin/bash EEPROM_ADDR0x50 IMAGEswitch_eeprom.bin PAGE_SIZE32 python3 - EOF pages.txt image open(switch_eeprom.bin, rb).read() for offset in range(0, len(image), 32): page image[offset:offset32] print(offset, page.hex()) EOF while read offset hexdata; do data($(echo $hexdata | sed s/../ /g)) i2cset -y 1 $EEPROM_ADDR $((offset 0xFF)) ${data[0]} ${data[1]} ... sleep 0.01 done pages.txt这种 Shell 实现比较粗糙主要是演示了“按页写、注意等待”的思路。更可靠的做法还是直接用 Python 的 smbus 库把页写和回读校验都写在同一个脚本里。写完之后一定回读逐字节比对这是烧录最终环节也是确认 EEPROM 没坏的最快方法。回读比对通过后再断电让芯片重新上电观察芯片是否真的把配置加载进去。4.3 上电后的验证三板斧第一板斧看灯。如果端口 LED 能按时序亮灭至少说明芯片内部时钟、核心复位和端口初始化没有大问题。LED 闪烁行为如果完全不对先回头查 strap 和 EEPROM 读取是否成功。第二板斧抓包。找两台测试终端一个插千兆接入口一个插万兆上联口配置好业务 VLAN打双向流量。抓包能直接验证二层转发是否正常也能顺便看出是否出现广播风暴、CRC 错误等物理层问题。这里要注意抓包口要选对别插在一个没有加入业务 VLAN 的端口上否则抓不到任何流量容易误判。第三板斧回读寄存器。通过 SMI 口连上调试主机用 mdio 工具读几个关键寄存器看看实际值和 EEPROM 里烧进去的值是否一致。这里不需要读全部读“端口状态”“VLAN 表生效”这类关键寄存器就够。比如读端口状态寄存器能确认端口是否处于 link up 状态读 VLAN 表相关寄存器能确认表项真的被加载了。# 读取某个端口寄存器确认端口状态 mdio-read -q -r 0x0000 -p 0x10 eth0如果没有 mdio 工具也可以用逻辑分析仪抓 SMI 时序确认启动过程中芯片确实发出了读 EEPROM 的波形。三条路交叉验证基本能把“烧进去但没有生效”“生效但转发不对”两类问题定位清楚。5. 排障实录你大概率也会遇到的几个坑5.1 EEPROM 读不出来多半是 strap 或地址线我遇到的第一种典型故障是EEPROM 烧录了反复回读也正确芯片上电后就是按默认逻辑跑配置完全没有生效。排查到最后发现 strap pin 被原理图上的默认电阻固定到了“禁用 EEPROM 启动”的位置。这种问题最坑的地方在于它不会报错只会表现为“配置丢了”。排查思路很简单先把 strap 组合和手册里的 boot mode 表核对一遍确认 EEPROM 启动被使能然后用逻辑分析仪看 EEPROM 的 I2C 总线上电瞬间有没有读波形。如果完全没有波形九成是 strap。如果波形有但读回来全是 0xFF查 I2C 地址线和 EEPROM 焊接。如果数据能读回来但校验失败查镜像格式和 CRC。5.2 SerDes 协商不稳定先回读 PHY 状态端口时亮时不亮丢包率很高这种问题在 No-CPU 模式下非常让人头疼。因为你不清楚究竟是 SerDes 配置不对、外部 PHY 没初始化还是链路另一端的设备协商方式不匹配。我的处理顺序是先把链路两端都固定成同一个速率和双工模式不要开自动协商自动协商在这种静态配置场景里反而容易出幺蛾子。然后通过 SMI 读 PHY 状态寄存器重点看 link status、speed、duplex 和接收信号稳定标志。如果读到的状态是链路已连接但对端速率猜错调 SerDes 侧速率再试如果是 PHY 完全没有响应检查 PHY 的复位脚和时钟。这里提醒一句很多 PHY 的默认地址不是 0且地址脚的上拉下拉组合必须在原理图阶段就固化好No-CPU 模式下没有软件能帮你改 PHY 地址。5.3 配了 VLAN 还是互相广播先查 PVID 和成员关系这种故障的表现通常是业务 VLAN 不通但整个交换机像傻瓜交换机一样广播风暴。我一开始以为是 VLAN 表没写进去回读表项却发现一切正常后来才意识到问题出在 PVID 上。在很多交换芯片里收到的 untagged 帧会先打上端口 PVID 的 tag如果端口 PVID 不在该 VLAN 的成员列表里帧就会被丢掉或转入默认行为。所以在配置 VLAN 时必须把三层信息对齐端口的 PVID、端口的 member 列表、VLAN 表项里的 untagged 位。三层之间任何一个不一致表面上注册了 VLAN实际转发路径还是断的。我后来写了一个脚本生成镜像前自动交叉校验三张表这种低级但致命的问题就少了很多。5.4 换到 88Q5152 时这套流程能留下什么如果你后续会接触 Marvell 其他交换芯片比如 88Q5152 这类面向车载或工业的器件会发现配置思路高度相似同样依赖 EEPROM 启动、通过 strap 选择启动源、用寄存器写初始值。差别主要在这些车规/工业芯片对可靠性要求更高EEPROM 烧录通常要被纳入产线流程还要加安全启动、防回滚等机制。坦白说那次做完 88E6390X 的 No-CPU 项目之后我再看到 Marvell 交换芯片相关的选型第一反应已经不是选哪颗 CPU 了而是先问这个产品的固定行为能不能用一次干净的寄存器初始化覆盖如果答案是可以那就值得沿着 No-CPU 这条少一点存在感却足够稳的路线继续走下去。开发时多备几片 EEPROM多留一个调试接口把镜像生成脚本做成工程化后期量产和现场维护都会轻松很多。我个人强烈建议第一次做这类项目时先把最小可转发配置跑通再逐步加 VLAN、加镜像口、加 QoS 这些需求这比一开始就想把整张寄存器表烧全要靠谱得多。
