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物理介面，單設備組網能力極大增強，
本文提供的內容僅供參考，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/217525.html
標籤：其他