平台

主控芯片arm：ast1520
Linux内核版本：2.4.6
uboot版本：1.1.4

概述

原来的主控芯片连接的是一个phy芯片，采用的是mac控制器连接phy芯片的方式。现在的需求是把phy芯片换成了交换芯片RTL8367，并且采用mac to mac的方式进行连接。也就是arm的mac控制器直接连接到交换芯片的mac口，连接速度与连接方式都是固定的。

分析

该交换芯片支持I2C、SPI、mdio通信，但是看ast1520的uboot代码采用的是mdio去通信phy芯片的，所以暂时也先采用mdio的方式，需要配置相应的引脚才可以配置成mdio通信模式，具体的配置硬件工程师解决。
ast1520的uboot中带有mdio的读写操作命令，为phyw/phyr

mac表示使用的是mac1还是mac2，phy addr表示的是phy id，芯片手册上会有介绍，寄存器就是通用phy寄存器。

了解一下mdio协议

RTL8367交换芯片详解

IEEE规定了，所以的phy芯片寄存器，前16个都是通用的，也就是说任何一个phy芯片，按理来说只要配置前面16个寄存器就可以完成基本的上网功能了。后面的16个phy寄存器，都是厂商自定义的功能。但是对于交换芯片来说，因为含有多个phy芯片，也就是utp端口，也含有Gmac端口，所以配置的选项很多，一般交换芯片都还会有自己的寄存器，如果是用I2C来访问，可以直接访问寄存器的地址来实现；如果通过mdio访问，则需要访问相应的phy寄存器来间接访问自己的寄存器，如8367就是这样的：

移植交换芯片代码在板子上跑起来后

目前rtl8367与ast1520之间125M时钟双向都有了，但是还是ping不通外面的网络；对于交换芯片来说，你没有去配置它，它会有默认的寄存器值，而默认的寄存器值那些网口就是通的，8367就是这样。不需要去配置它的任何寄存器，默认的8367的phy端口就是通路。
因为目前ast1520是采用飞线的形式与RTL8367连接起来的，飞的线包括mdio连接线与RGMII连接线。因为网络对于实时性与时序上的要求很高，如果采用飞线的形式，误码率与速度都差得很大，特别是在千兆网络下，基本是不可能ping通的采用飞线形式，所以先考虑降低网络速度，RGMII并不是只能跑千兆网络，它还可以跑百兆十兆的网络，看8367的芯片手册

目前把两端都配置成10M，时钟都是2.5Mhz，还是不通，下一步考虑读取交换芯片寄存器了。
疑问1：配置成10M通信模式，但是外面utp口不是10M的，能ping通吗？
拿demo板做实验。好叭，也是可以ping通的，那就是ping包跟网络速度没有关系；然后还发现了一个实验现象，当采用10M进行通信的时候，不用加rx_delay与tx_delay也是可以通信上，当进行千兆网络通信时，如果不加rx_delay与tx_delay的话就会有问题，可能因为千兆通信速度快了，需要的时序要求也更高了。
疑问2：ping包的时候会有数据产生吗？
一定会的，量取demo板上得交换芯片ping包的时候的数据线，能量取到对应的数据。

还是ping不通，怎么办，继续思考

先捋一下状态，现在的情况是配置成了10M网络，时钟两端都量取到了，都是2.5Mhz，按理来说也没有什么好设置的了，那么只好再去量取对应的信号数据线，因为采用的是飞线的形式，所以很有可能硬件上还不是好的，很容易短路。
量取ping包时的数据线，是有数据的，当然并没有在意数据是什么样子，后面仔细看数据信号，才发现数据线拉不低，与硬件一起看，发现是飞线的时候短路了，导致数据线拉不低。修改硬件后，再次量取数据线，发现正常了。
但是还是ping不通，蛋疼，把相同的配置在IP5600的RTL8364上实验，是可以ping通的，思考了很久，用抓包工具抓一个包试下吧，发现一抓，看到了主控芯片通过RTL8367发到了电脑，并且电脑上的抓包工具抓到了ast1520的ip地址，但是回应的时候却出现了问题，电脑是回应了的，主控芯片却没有收到。与硬件沟通，再次挨个量取信号，发现

这个引脚没有数据，也就是没有波动，再次量取demo板的对应的线，发现该根线是有数据波动的，所以查看ast1520的飞线板子，最后发现这条线飞错了，重新弄一下之后，好了。