国产ARM64平台集成RTL千MSwitch芯片

0 概述　　

　　近期负责一新案子，采用国产ARM64平台方案，定位于车载后装，该方案需集成RTL Switch芯片。
　　国产平台的好处可归结为资料都是中文版，HDK/SDK都是能用的，HDK一般已经过验证，有核心芯片推荐名单录；其SDK能一次性编译过。当然，一如既往地，提供的配套资料稀少，除掉文档结构性文字，可用的干货就更少；文档所描述的内容非常简单笼统，能搞晕未曾接触过此类方案的研发工程师。
　　因为我们对HDK进行了大改动，替换了主屏方案和以太网方案，并增加了业务需要的一些其它器件。这一替换就出了一系列问题，其过程艰辛又痛苦。为此，特写了此文档，希望能帮到他人。
　　RTL的单PHY芯片因为其连线简单，单价便宜，购买方便，且标准Linux平台又直接支持，所以几乎在所有的ARM平台方案上都用此了PHY为标配，在盒子、车载和手柄设备上到处可见。但就RTL的Switch芯片来说，其使用场景就急剧缩窄了，常见的也就是家用型普通傻瓜交换机了。在RT领域，除了RTL自己的方案平台,BCM和MTK的部分方案上也采用此方案。虽然OPENWRT下有RTL8367系列的驱动，但相对来说，资料匮乏、网上经验稀少，新方案中采用此类交换芯片的风险特别高。在项目前期，因为已有成功量产包含8367交换芯片的RTL WiFi路由器经验，所以我们才敢集成此芯片。

1 硬件调试　　

　　相对来说，RTL的Switch芯片的硬件调试工作比较简单，毕竟，只要供电正常，傻瓜式交换功能还是较容易调通的。　　

　　首先在硬件上，要注意8367交换芯片的RGMII接口，是接GMAC1或GMAC2的，所以，它是一个RGMII MAC方案，而一般的ARM64平台，其内部也实现了MAC，所以，主控和8367交换芯片间的连接，是RGMII MAC 接RGMII MAC的连接方式；同官方HDK上的直连单PHY的接线方法完全不一致。具体要如下图所示。如果接反了，有12条线要飞，如果不是0602的料，焊工技术要求高。

 

（本图源自MTK7621）

 　　其次要针对datasheet，检查交换芯片上LED引脚的复用问题，高低电平不要搞错了，如果可能，将高/低电平连接点都做在PCB板上引出，调试的时候，可以灵活连接。

　　最后，要检查交换芯片自身的功能是否正常，从而证明芯片的供电是否正常。因此建议至少引出2个RJ45口，一根线接电脑，另一根接路由器，如果电脑能获得IP地址，则表明交换芯片自身受电正常，内部工作正常。万一异常了，就要检查各个连线的电压是否正常，只要电压正常了，芯片就能正常工作。外围一共不到20个电阻电容，每个连接点都排查一下。

　　一般来说，如果增加了新芯片，出问题时，芯片商会要求你找主方案商；而主方案商又会要求你去找芯片商的。故不到万不得已，不要增加新芯片。最佳实践是能找到优质的主芯片代理商和/或芯片代理商，但实际中非常难找到，所以只能相信自己的团队，不到提升团队人员的技能。

 

2 软件调试

　　真正的调试工作量都在软件上。
　　首先，要了解现有的SDK上的MAC和ETH的实现流程，较新的SDK平台，都是通过MDIO BUS来实现PHY控制的，所以建议务必研读一下现有的mdio-bus流程代码。像我们做获得的SDK上，其MAC和ETH实现非常简单，公开的不同寄存器才27个，比PHY寄存器还少。更甚的是后台代码才4400多行，非常精简，一天时间就能摸透其管理与报文收发流程了。不过，这里要强调的是，在Probe中，虽然已经调用了hw init功能，但它的MDC/MDIO信号功能是未启动的，即使GPIO已经明确复用为以太网了，此时去操作MDC寄存器，是无效的，抓不到任何波形。务必要到拉起ETH后，此类寄存器才生效。我们就是在这里折腾了好几天。
　　其次，8367系列交换芯片的PHY寄存器读写，不能按经典PHY寄存器读取方式去操作。可以参考Linux平台现有的rtl8366_smi中的读写PHY寄存器的方式，重构SDK中modi-bus读写PHY寄存器的实现。这个集成非常简单，但我们在集成的时候，前期只关注了ASIC内部寄存器的读写，没有重视PHY寄存器的读取方式，导致始终取不到PHY ID，老是提示找不到PHY。
　　最后，要自己写驱动，新一点的交换芯片，无论是直接集成RTL官方SDK中的8367驱动，还是从网上找ASUS路由器驱动或OPENWRT中的开源驱动，可能都不能成功驱动8367交换芯片。经过验证，利用ASUS路由器上开源出来的驱动，会导致PHY ID错误，也可能是我们的现有的Switch芯片过新造成的；而用RTL　SKD中驱动，无论调用8367_init还是8367_init_switch_mode，均不能正常工作。推荐用ASUS路由器中8367的驱动架构，同时将API换为2017年以后的，重写8367驱动代码。针对RGMII接口，8367要开启CPU端口功能，且将GMAC1或GMAC2绑定为CPU端口。VLAN功能可先关闭。基于有限的PDF文档，要成功配通8367的VLAN功能，纯属运气活。API中的VLAN功能都是零散的，组合起来用，往往与预期目标相差甚远，按照其提供的配套PDF文档中的指令序列配置VLAN后，最可能的结果导致各端口间不通，或与上游路由器不通，从而设备联网失败。
　　因为RGMII MAC-MAC的特殊连接方式，会导致主控侧的网络Link状态维护比较特殊。可通过如下2种方式维护：其一，在phy_state_machine中，将链路状态改为PHY_RUNNING，直接netif_carrier_on起来PHY接口；同时，在genphy_config_init强制1000M；这样，只要拉起以太网接口，Link状态立即为UP。缺点是交换机的物理端口没有连任意网络接口，也是UP状态，用户体验不佳；其二，主控这边对PHY寄存器的读写，集中在Port0上；这样，在Port0上插拔网线，会看到ETH接口的Link状态变化，比方法一似乎要好些。缺点是，在Port0上未插网线时，当设备工作在固定IP模式下后，只要其它Port（启动用了VLAN时，必须是同一个VLAN组的Port）插了网线，主控还是可以同网络上其他设备通信的。最好是在需要时，维护各Port的链路状态，同时，修正ETH的状态，比如所有Port都未连线时，ETH才是DOWN状态；否则，都是UP状态。

　　实在不知道主控端是否将报文成功发送到RGMII接口时，可以在主控的驱动中，每发送一个报文后，去读一下8367的RGMII接口的统计报文数，如果与预期相差不大，则表明报文成功发送到了交换机上；否则，需要定位主控侧发出的报文，在哪里丢失了。

3 其它 　　

　　总之，将一个Switch芯片集成方案到国产的ARM平台方案，从而实现将车载设备/盒子等单网口设备改为多网口设备，对扩宽业务还是非常有帮助的。从联网能力上看，8367交换芯片，可提供5-7个物理千M物理接口，单设备组网能力极大增强。

　　本文提供的内容仅供参考。