鋒影
email:[email protected]
如果你認爲本系列文章對你有所幫助，請大家有錢的捧個錢場，點擊此處贊助，贊助額0.1元起步，多少隨意
-->ifconfig
fec0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
address: 00:00:12:34:56:78
media: Ethernet 10baseT full-duplex (none)
status: no carrier
inet 192.168.1.11 netmask 0xffffff00 broadcast 192.168.1.255
inet6 fe80::200:12ff:fe34:5678%fec0 prefixlen 64 scopeid 0x11
--> nicinfo
fec0:
i.MX6 Ethernet Controller
Link is DOWN
Physical Node ID ........................... 000012 345678
Current Physical Node ID ................... 000012 345678
Current Operation Rate ..................... Unknown
Active Interface Type ...................... MII
Active PHY address ....................... 0
Maximum Transmittable data Unit ............ 1500
Maximum Receivable data Unit ............... 1500
Hardware Interrupt ......................... 0x96
Hardware Interrupt ......................... 0x97
Memory Aperture ............................ 0x2188000 - 0x2188fff
Memory Aperture ............................ 0x2098000 - 0x2098fff
Promiscuous Mode ........................... Off
Multicast Support .......................... Enabled
與QNX的網絡工程師交流得知：status: no carrier是由於當前phy的link狀態是down的，所以status 是no carrier的。
所以當前問題歸根結底是：當PHY初始化完成之後，PHY與電腦對接後一直處於DOWN狀態。層層定位後發現是由於ar8035配置了自協商之後，端口變down了，但是PHY芯片肯定是要配置自協商的。
順便補充一下：QNX的sambreARD默認適配的是AR8031，而我編譯好的ifs文件在8031的板子上網口是可以正常工作的。所以當時的思路只有一個：就是查看ar8031和ar8035數據手冊的差異。
1、PHY Address
獲取PHY的物理地址，QNX是通過MDI_FindPhy 接口配置的。遍歷32位來查詢當前的PHY的地址，添加日誌
之後發現當前PHY的地址爲0。
在電路圖中NC表示不接的意思。所以LED_ACT/RXD1/RXD0都是直接接地。所以PHY的物理地址爲0.與
軟件識別到的地址是一致的。
2、Mode Select
當前硬件電路上的PHY MODE是1100 （NC表示斷接），根據AR8035的手冊，可以看到當前的MODE配置爲：
RGMII,PLLOFF,INT
RGMII表示數據通信的接口，MDIO表示MAC對PHY的控制接口；
PLLOFF：表示芯片可以關閉內部PLL，以達到節能的目的。具體做法是：當進入節能模式之後,
25M時鐘的輸出將會週期性的消失。但在PLLON模式，25M時鐘的輸出將是連續的，
AR8031和AR8035芯片的主要區別是：AR8031支持光口和電口；而AR8035僅支持電口。
光口和電口的配置就是通過mode select的硬件電路來配置的。具體差異如下：
AR8031Mode Definition:
AR8035 Mode Definition:
3、查看PHY配置
通過DUMP PHY的寄存器，發現8031和8035的寄存器的配置都是相同的。由於當初購買的開發板帶的是
linux系統，所以就查看linux中ar8031和ar8035的差異（kernel_imx\drivers\net\phy\at803x.c）。發現8031和8035
註冊的接口都是一樣的，僅PHYID不同；在linux內核工程裏面搜索該PHYID，發現沒有做特殊處理的地方。因而
對於linux 網絡驅動框架而言，並不關注當前的PHY是什麼芯片，框架都是做同樣的處理。所以當初的思路就變
爲排查MAC的配置，當從網絡驅動的入口函數 fec_main.c中的fec_probe函數開始排查，發現在代碼中會調用
fec_reset_phy函數來對PHY做硬件上的復位，即通過reset管腳來複位。到此，在QNX BSP中在調用mx6q_init_phy
之前添加對PHY硬復位的代碼。由於當前代碼編譯到so的，也就是用戶態的程序，所以不能直接操作imx6q的
硬件寄存器，所以只能通過mmp來做映射:具體代碼如下：
// reset phy by hardware
gpio_base_addr = mmap_device_memory (NULL, /*MX6X_GPIO_SIZE,*/MX6Q_MAP_SIZE,
PROT_READ | PROT_WRITE |
PROT_NOCACHE,
MAP_SHARED,
/*MX6X_GPIO1_BASE*/0x0209C000); //GPIO1
*(gpio_base_addr + 0) &= (~(1<<25));
nic_delay(1);
*(gpio_base_addr + 0) |= 1<<25;
/* unmap the address have been mapped*/
munmap_device_memory(gpio_base_addr, MX6Q_MAP_SIZE);
// Do one time PHY initialization
if (mx6q_init_phy(mx6q)) {
log(LOG_INFO, "PHY init failed");
mx6q_destroy(mx6q, -1);
return ENODEV;
}
設備上地址映射只能通過mmap_device_memory，內存上的地址映射可以用mmap，注意兩者的區別。
重新編譯後，網口可以正常工作。