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物理接口，單設備組網能力極大增強。
本文提供的內容僅供參考。