交换机基础知识

交换机处于网络中的位置

以太网帧结构

端口

二层转发原理

VLAN

聚合

ACL

QOS

典型网络接口分析

SMI

SMI 是MMI管理总线具有 MDIO和MDC两根线，它允许带有smi的外部设备控制PHY的状态以及内部寄存器。

MII接口

MII（Media Independent interface）即介质无关接口，它是IEEE-802.3定义的行业标准，是MAC与PHY之间的接口。MII数据接口包含16个信号和2个管理接口信号，如下图所示：

RMII接口

RMII接口有12个信号线，节省了一半的数据线 ，主要包括四个部分。一是从MAC层到物理层的发送数据接口，二是从MAC层到物理层的接收数据接口，三是物理层与MAC层之间时钟接口，四是MAC层和物理层之间数据管理的MDIO/MDC接口。

其中CRS_DV是MII中RX_DV和CRS两个信号的合并，当物理层接收到载波信号后CRS_DV变得有效，将数据发送给RXD。当载波信号消失后，CRS_DV会变为无效。在100M以太网速率中，MAC层每个时钟采样一次RXD[1:0]上的数据，在10M以太网速率中，MAC层每10个时钟采样一次RXD[1:0]上的数据，此时物理层接收的每个数据会在RXD[1:0]保留10个时钟。

GMII接口

GMII（Gigabit Media Independant Interface），千兆MII接口。GMII采用8位接口数据，工作时钟125MHz，因此传输速率可达1000Mbps。同时兼容MII所规定的10/100 Mbps工作方式。GMII接口数据结构符合IEEE以太网标准，该接口定义见IEEE 802.3-2000。信号定义如下：

综合分析网络接口都具有几根共性的线：

时钟线：都是由PHY侧向MAC侧提供时钟

SMI线：管理PHY寄存器

RXDV: PHY侧向MAC侧告知数据发送

TXEN：MAC侧向PHY侧告知数据发送

典型交换芯片分析

CPU集成MAC外接switch芯片，switch内部一般是N个PHY和N+1个MAC，通过CPU的MAC与Switch的MAC使用MII/RMII等接口MAC-MAC方式连接

为了可以进行这样的连接，switch与CPU连接的那个MAC口通常可以配置成PHY模式，这个时候从CPU的角度来看，switch与之连接的端口可以看成一个PHY。

RTL8306MB

RTL8306MB-CG是6端口10 / 100M以太网交换机控制器，将用于10Base-T和100Base-TX操作的内存，六个MAC和五个物理层收发器集成到单个芯片中。它支持（T）MII / RMII接口，以使外部设备连接到第六个MAC。外部设备可以是路由引擎，HomePNA，HomePlug或VDSL收发器，具体取决于应用程序。

特征：
基本切换功能
具有存储器和收发器的6端口开关控制器，用于10Base-T和100Base-TX
无阻塞线速收发，无阻塞头转发
兼容IEEE 802.3 / 802.3u自动协商
内置用于数据包缓冲区的高效SRAM，具有2K条目查找表
2048字节最大数据包长度
完全支持流量控制
半双工：背压流量控制
全双工：IEEE 802.3x流控制
支持与外部MAC或PHY的（T）MII / RMII接口连接

支持最多16个VLAN，并且支持VLAN学习，带有四个独立的IVL过滤。

应用领域：
6端口交换机（10Base-T和100Base-TX）
xDSL /电缆调制解调器路由器或家庭网关应用
HomePNA / HomePlug桥解决方案

RTL8306MB可以通过硬件管脚将MAC5 配置成三种模式：MAC MODE(MII ) , PHY MODE(MII) ，RMII MODE。

交换芯片调试过程

交换芯片SDK移植

其中RTL8306E管理接口为MDC/MDIO，MDC为时钟，MDIO为传输数据..源代码使用两个GPIO引脚来模拟MDC/MDIO信号。将此驱动程序移植到客户平台需要创建文件mdcmdio.c和mdcmdio.h。在这些文件中， 需要实现smi通信逻辑 。如果已经有SMI读写接口再包装一层即可。

此外还要注意另一个问题，即在SMI读取和写入期间，防止CPU被打断 ，因此在SMIREAD和SMIWRITE中，需要关闭中断以及调度。

在完成底层的配置后需要依次调用SDK接口函数进行交换芯片的初始化，主要就是VLAN,PVID的配置。

问题1 GMAC无法收发问题

问题背景

在这个项目中的rtl8306MB的mac5 就是被配置成RMII MODE ，首先在进行SMI总线调试的时候非常顺利，可以使用SMI读出chipid , 读写交换芯片配置信息。但是在调试RMII总线的过程中发现switch的MAC5没有任何收发包的记录，cpu也没有任何收发包的记录。所以就准备先用示波器寻找原因。

问题解决

我们首先判断RTL8306MB没有配置成RMII模式，也就是说时钟可能没有通过时钟线从RTL8306MB芯片传输到CPU中，所以首先通过示波器读取时钟信号，在硬件上需要断开时钟信号，然后分别读取时钟线两边的信号：

读取后发现switch侧有50M时钟，MAC侧无时钟，说明RMII模式配置正常。

然后读取数据线上的数据，因为数据线是独立的，所以每一边只要测差分信号的其中一根就行：

我们首先通过电脑向switch芯片发包然后读取switch芯片和CPU之间的 TXD数据线：

然后使用cpu通过发包函数，向switch发包:

发现 两边的数据线上都是有数据的，这就说明两边都是正常进行发送的。

然后测试TXEN,RXDV

TXEN:

发现TXEN有信号，而RXDV一直没有信号。

所以判断硬件上是不是将TXEN和对端的RXDV 接了起来，为了判断是否是这个问题，我们将TXEN线上的串阻卸下然后在串阻的两端同时检测到使能信号：

所以MAC侧和PHY侧的使能信号竟然同时出现在了TXEN信号上。所以就可以确定就是将两端的TXEN和RXDV接起来了。飞线之后发现GMAC收发包正常。

查看芯片手册：

从芯片手册上来看，硬件同事犯了一个非常容易犯的错误，因为在RMII默认就是PHY模式，所以将TXEN,和RXDV搞反了，导致了两端的TXEN接到了对端的RXDV上，导致两端都无法收到使能信号，导致GMAC通信异常。

问题2 应用层协议栈无法收到数据包

问题背景

在解决了GMAC数据收发问题之后，我可以在接收回调函数中收到从SWITCH发出来的报文，并且发出的报文也可以通过switch发送到面板口。但是应用层的协议栈却并没有工作。

问题解决

在研究了代码之后发现 应用层无法收到报文的原因是他们的接收回调函数中在检测proto的数值的时候总是会被过滤调，因为proto总是一个固定的数值0x8100。为了找到原因，我将data打印出来，发现比我发送的报文多出了四个字节。这个四个字节正好替代了原来代表协议类型的字节位置。

为了分析这里收到的报文没有做处理的原因我在这里做了打印：

构造ARP报文发送

1口发送 接收到的报文

2口发送接收到的报文

查看了报文结构发现多出的就是VLAN TAG，因为在switch配置的时候，我将cpu口设成了TAG，而协议并没有对此做处理。

在我将所有口都设成是UNTAG之后，问题解决。