：從硬件鏈路到千兆轉發(fā))
簡介面向嵌入式網(wǎng)絡設備開發(fā)場景這套源碼資源聚焦RK3568處理器與YT9215交換機芯片的驅動程序適配適用于從事Linux內核驅動、硬件接口調試的工程師學習參考。壓縮包共2個文件包含1個.c源文件和1個.h頭文件整體大小僅4KB其中.c源文件主要實現(xiàn)設備初始化、數(shù)據(jù)收發(fā)與中斷處理等驅動核心邏輯.h頭文件則定義驅動所需的結構體、常量與函數(shù)聲明兩者配合構成一個精簡可研究的驅動模塊。目前已有5129人瀏覽學習說明該主題在同類調試場景中有一定代表性。參照這兩個文件可梳理出從設備樹描述、驅動注冊到收發(fā)測試的完整思路。同時也能輔助定位硬件接口分析及驅動代碼編寫階段的常見問題為后續(xù)優(yōu)化與維護提供直接參考。1. RK3568 YT9215 在做什么從多網(wǎng)口需求到交換機芯片一塊 RK3568 的板子原生網(wǎng)口通常只有兩三個而一臺千兆交換機的需求往往起步就是四個千兆口起步有的還要帶光口或 PoE。與其換主控不如在 RK3568 的 PCIe 或 SGMII 接口上外掛一顆 YT9215 交換機芯片把網(wǎng)口數(shù)量一次性擴到五六個。方案聽起來順理成章但真正把板子拿到手開始調的人都知道這從來不是“插上就能用”的活。YT9215 不是普通 PHY它是一顆帶完整交換內核的芯片上電后默認配置可能連 CPU 端口都不通MDIO 讀不到 ID、寄存器寫不進去、內核里根本沒有對應驅動這才是常態(tài)。這篇文章要講的就是我在 RK3568 上把 YT9215 從頭調到能跑滿千兆的完整路徑適合正在做多網(wǎng)口網(wǎng)關、工業(yè)交換機或邊緣計算底板的開發(fā)者內容會一直寫到驗證工具和坑的解法。2. RK3568 與 YT9215 的硬件鏈路接口選型與上電檢查2.1 接口選型SGMII、RGMII 還是 PCIeRK3568 與 YT9215 之間的連接方式?jīng)Q定了我后續(xù)所有調試路徑的走向。常見的接法有三種SGMII、RGMII 和 PCIe。YT9215 這類交換芯片通常帶有多個 SerDes 通道通道可以被復用成 SGMII 接口連接主控也可以配置成 PCIe RC 模式或者作為 PCIe EP 被主控枚舉。硬件設計階段選哪種直接決定驅動方式是把它當普通 PHY 用還是當 PCIe 交換機用。我一般會優(yōu)先選 PCIe原因很實際。RK3568 原生 PCIe2.0 控制器打開后YT9215 會被識別成一個 PCIe 設備Linux 自帶的 switchtec 或者 mdio 觸達方式更靈活吞吐量上限也高SerDes 跑 5Gbps 跑滿千兆毫無壓力。如果板子上 PCIe 通道已經(jīng)被 NVMe 或 Wi-Fi 占用那就退一步用 SGMII把 YT9215 接到 RK3568 的 GMAC 控制器上讓 Linux 把它當作一個“帶內部交換功能的 PHY”。RGMII 是最后的選擇16bit 數(shù)據(jù)線布線要求高頻率跑不上 1000Mbps 以上速率只適合低成本的百兆場景。選型這件事上踩過的最大一個坑是把 PCIe 通道復用當成理所當然。RK3568 的 PCIe2.0 控制器和 SATA、USB3 之間本身就存在引腳復用硬件工程師如果沒在原理圖階段確認引腳的 mux 配置板子回來之后 PCIe 怎么都枚舉不到。軟件上可以通過修改 pinctrl 節(jié)點做嘗試但如果硬件上已經(jīng)走線錯誤系統(tǒng)端是無能為力的。2.2 上電前的硬件檢查先量電壓再做時鐘測量很多 YT9215 調不通的案子根因并不在軟件而是硬件細節(jié)不規(guī)范。YT9215 這類交換芯片比普通 PHY 復雜供電通常有 1.0V 核心電壓、1.8V 和 3.3V 三個域而且對上下電時序敏感。拿到板子第一步我習慣用示波器同時測三路電源的上升沿確認 1.0V 不要比 3.3V 先掉電。這個看似玄學的問題實際導致的典型故障是芯片經(jīng)常第一次能工作、重啟后失聯(lián)而且用萬用表量電壓全是正常的不加示波器根本發(fā)現(xiàn)不了。之后必須測量 YT9215 的時鐘輸入。25MHz 參考晶振是這顆芯片正常工作的基礎測的時候不要只看有沒有波形要關注頻率偏差超過 50ppm 的信號會影響 SerDes 的位同步表現(xiàn)為主控側鏈路反復 training 失敗。另外一個容易被忽略的是復位引腳的上電釋放時間YT9215 的復位釋放要晚于所有電源穩(wěn)定至少 10ms很多 ARM 板上的 GPIO 復位是系統(tǒng)起來之后才拉高導致第一次上電時芯片復位釋放時電源還沒完全穩(wěn)定后續(xù)初始化一團糟。硬件檢查做完后我習慣在 uboot 階段先做一個最基礎的探測。如果走的是 PCIe 連接在 uboot 命令行里直接執(zhí)行 pci enum然后查看設備樹中 PCIe 控制器是否識別到了設備。如果 VENDOR ID 讀出來是 0xFFFF說明物理鏈路就有問題這時候我會直接量 SerDes 的差分信號是否在輸出排除主控側 PCIe 控制器沒有正常 link up 的情況。Rockchip U-Boot pci enum Rockchip U-Boot pci 0執(zhí)行后如果沒有任何設備號顯示把 dmesg 打開看 PCIe 控制器報錯信息重點找 PHY PLL lock 失敗和 LTSSM 狀態(tài)的打印。LTSSM 停在 Detect 狀態(tài)基本就是時鐘或復位問題停在 Configuration 之前的狀態(tài)則大概率是 SerDes 通道配置不一致。2.3 用 devmem 驗證 YT9215 是否在總線上可見在 Linux 系統(tǒng)起來之后第一件事不是急著配置 switch而是確認 YT9215 在地址空間里可訪問。PCIe 連接的情況下查看 /sys/bus/pci/devices/ 目錄下多沒多設備再用 setpci 看配置空間里的 VENDOR ID 和 DEVICE ID。rootboard:/# ls /sys/bus/pci/devices/ 0000:01:00.0 rootboard:/# setpci -s 01:00.0 vendor_id如果讀到 ID 正常說明物理鏈路已經(jīng)打通了。這時候直接讀寫 YT9215 的寄存器空間還是借道 PCIe config space 或者是 BAR 空間映射取決于這顆芯片的設計。常見做法是 YT9215 會提供一塊內部寄存器映射通過 PCIe BAR0 窗口暴露給主控。可以用 devmem 把 BAR0 的地址映射出來直接讀芯片的 ID 寄存器驗證訪問通路。rootboard:/# setpci -s 01:00.0 base-address-0拿到 BAR0 的物理地址之后用 devmem 讀芯片內部基地址偏移處的 chip ID 寄存器。如果讀出來的值和 datasheet 里寫明的一致說明從主控到芯片的訪問通路完全正常接下來才有必要繼續(xù)做 PHY 的配置。如果 devmem 讀出來是空或者全 F那就意味著 BAR 窗口沒有正確映射先回頭查 PCIe 的 memory space 分配是否正確。3. 把 MDIO 和 PHY 狀態(tài)打通最小驅動加載路徑3.1 最小驅動加載路徑從設備樹描述一張外掛設備YT9215 在 Linux 下沒有現(xiàn)成驅動的概率很高內核 mainline 未必會收錄這顆芯片的完整 switch 驅動。常見做法是把它當作普通的 MDIO 設備來描述讓 Linux 的 MDIO 總線框架管理起來再由用戶態(tài)工具直接操作寄存器完成核心的配置工作。在設備樹里我一般會在 GMAC 節(jié)點下面掛一個 mdio 子節(jié)點然后描述這顆 PHY。這種描述方式的最大價值在于讓內核的網(wǎng)絡子系統(tǒng)認為這個端口上連著一個 PHY從而 eth0 這個網(wǎng)絡設備能正常 up后續(xù) MDIO 的訪問路徑也是通的。設備樹描述示例如下gmac0 { status okay; phy-mode sgmii; mdio0: mdio { compatible snps,dwmac-mdio; #address-cells 1; #size-cells 0; switch_phy: ethernet-phy1 { reg 1; compatible ethernet-phy-id1234.5678; }; }; };這里的 phy-mode 根據(jù)實際硬件連接方式填寫如果走的是 PCIe 連接就不需要這個描述直接用 PCIe 驅動去枚舉。ethernet-phy1中的 reg 是 YT9215 在 MDIO 總線上的物理地址這個地址取決于硬件上 PHYAD 引腳的上下拉配置不能隨意修改否則驅動會 probe 不到設備。compatible里的 ID 號要和 YT9215 的實際 PHY ID 對應起來大部分人這一步會卡住因為芯片里的 PHY ID 和 datasheet 上寫的不完全一致最穩(wěn)妥的辦法是先用 MDIO 工具讀寄存器把 ID 算出來再填。設備樹配好之后內核啟動日志里如果能看到 MDIO bus 上發(fā)現(xiàn)了一個 PHY說明內核已經(jīng)識別到設備。這時候 eth0 可能還沒有 IP但鏈路狀態(tài)應該可以從 down 變成 up。當然YT9215 有多組 SerDes 和多哥 PHY 端口需要在 mdio 節(jié)點下重復掛多端口描述后續(xù)每個對外網(wǎng)口才能有對應的 net_device。3.2 用 mdio-tools 直接驗證 PHY 寄存器內核識別之后不要急著寫驅動邏輯先用 mdio-tools 手動讀一遍寄存器。mdio-tools 是 mdio 讀寫工具集的常見實現(xiàn)一般在 buildroot 里勾選就能編譯進去。如果系統(tǒng)里沒有直接用 busybox 自帶的 mdio 命令也可以只是功能略少。我用的是 mdio-tools 的 mdio read 和 mdio write命令直觀適合一步一步踩。先讀 PHY ID 寄存器組標準 PHY 的 ID 寄存器的地址是 2 和 3。執(zhí)行命令之后把兩個寄存器讀取的值拼起來得到的是一個 32 位 PHY ID。rootboard:/# mdio read eth0 1 2 0x1234 rootboard:/# mdio read eth0 1 3 0x5678讀出來的 ID 值和 datasheet 里標準的 OUI 對照確認這顆 PHY 在內核的 PHY ID 列表里有沒有被定義。通常 YT9215 這種交換芯片內部的 PHY 核心 ID 是已知的但也不排除芯片廠家用的自定義 ID這種情況下要把 compatible 換成實際讀到的數(shù)字否則驅動 probe 不了。之后讀寄存器 0BMCR和寄存器 1BMSR看它們的默認值是否和 reset 后的狀態(tài)一致。rootboard:/# mdio read eth0 1 0 0x1140 rootboard:/# mdio read eth0 1 1 0x796dBMSR 寄存器里的 bit5 表示 autoneg completebit2 表示 link status。如果讀出來 link 狀態(tài)位為 0表示物理層沒有檢測到對端這并不一定是壞事因為 YT9215 的某些 SerDes 端口在默認配置下是處于低功耗或未啟用狀態(tài)的。此時可以嘗試手動配置 BMCR 寄存器強制 1000Mbps 全雙工再讀 BMSR 確認鏈路是否能起來。3.3 驅動加載失敗時的三處關鍵日志如果 mdio read 命令執(zhí)行不了或者 PHY ID 讀出來全是 F大概率是內核網(wǎng)絡設備沒有真正起來。這時候我會按順序排查三處日志。首先是 dmesg 里和 stmmac 或 dwmac 相關的行。RK3568 的 GMAC 驅動是 stmmac 框架日志里會打印 phy mode、MDIO 時鐘頻率、初始化狀態(tài)。如果打印顯示 MDIO 時鐘配置失敗檢查設備樹里 mdio 子節(jié)點的時鐘屬性通常需要顯式指定 MDC 的頻率上限否則總線的時序和 YT9215 不匹配。其次是 /sys/class/net 目錄下有沒有出現(xiàn)對應的 ethX 設備。如果設備樹里 GMAC 節(jié)點狀態(tài)沒有改為 okay整個 MAC 控制器都不會 probe自然沒有網(wǎng)絡接口。這個低級問題出現(xiàn)的頻率比想象中高很多時候是設備樹 overlay 沒有正確加載。最后是 interrupts 相關的報錯。YT9215 的 interrupt 引腳如果接到 RK3568 的 GPIO 上設備樹里必須配置正確的中斷號和觸發(fā)方式。中斷配置錯了表現(xiàn)為鏈路狀態(tài)變化時內核不感知即使物理連接恢復了網(wǎng)絡接口依舊顯示 down這種問題非常容易讓人困惑看起來像硬件壞了實際只是內核沒有收到中斷。4. 讓數(shù)據(jù)從網(wǎng)口真正走到 CPUPCS 環(huán)回與轉發(fā)配置4.1 先做 PCS 環(huán)回把物理鏈路的鍋關掉當 PHY 層已經(jīng)能正常 link但 ping 不通的時候先別急著查轉發(fā)邏輯在第一層做環(huán)回測試是最快的隔離手段。YT9215 這類芯片內部支持 PCS 層的環(huán)回把從主控 MAC 發(fā)出的數(shù)據(jù)在芯片內部直接環(huán)回到 MAC 接收側。這一步通過 MDIO 寫一個特定寄存器不需要外部接網(wǎng)線就能驗證主控到芯片之間的通路是否正常。rootboard:/# mdio write eth0 1 0x8000 0x0040這個操作的實質是設置 MII 控制寄存器里的 loopback 位。配置完之后從 eth0 ping 一個指定 IP 地址比如 192.168.1.1如果在環(huán)回模式下能 ping 通說明以太網(wǎng) MAC 到 YT9215 的 SerDes 通路是完好的。如果 ping 不通問題就出在 RK3568 的 GMAC 控制器配置或者 DMA 描述符鏈上沒必要去查后續(xù)的交換邏輯。PCS 環(huán)回測試通過后立即把環(huán)回位清除避免后面調試時數(shù)據(jù)平面被干擾。環(huán)回測試的另一個變種是 MAC 層的環(huán)回通過 RK3568 的 GMAC 控制器本身的 loopback 功能來做。兩者可以結合使用出現(xiàn)問題時能快速確認是主控側的問題還是 YT9215 側的問題。我在實際調試中最怕的就是這兩層問題交織在一起不做好環(huán)回隔離后面查 VLAN 和轉發(fā)配置時很容易被底層鏈路問題誤導。4.2 轉發(fā)路徑與 CPU 收包寄存器級最小配置YT9215 默認狀態(tài)下各端口之間未必自動轉發(fā)CPU 端口更是需要顯式配置。要把數(shù)據(jù)從某個 LAN 口送到主控的內核協(xié)議棧必須做兩件事讓 CPU 端口成為交換矩陣的成員端口并且配置 VLAN 和端口成員關系。YT9215 的寄存器空間里有一組端口控制寄存器我用 MDIO 寫的方式逐一配置端口使能和端口模式。常見配置是把所有端口設為千兆全雙工同時使能 802.1Q 的 VLAN 感知功能。最小化的配置是把所有 LAN 口劃入同一個 VLAN ID比如 VLAN 1CPU 端口也加入這個 VLAN這樣從 LAN 口收到的 untagged 數(shù)據(jù)幀會被打上 VLAN 1 的標簽并轉發(fā)到 CPU 端口。rootboard:/# mdio write eth0 1 0x2010 0x000F rootboard:/# mdio write eth0 1 0x2014 0x0008這兩條命令分別配置了端口使能位和 VLAN 成員表。寄存器地址的偏移量每顆芯片略有差異我這里寫的地址是 YT9215 一類芯片的常見布局實際使用時要以 datasheet 的寄存器偏移為準。這一步最容易翻車的地方就是把 CPU 端口的標簽位配錯。有些交換芯片要求 CPU 端口收上來的幀帶一個自定義的 tag不配置這個 tag 識別規(guī)則CPU 收到幀后會被網(wǎng)卡驅動當成錯誤幀丟掉。配置完成后用 tcpdump 在 eth0 上抓包從某個 LAN 口接一臺 PC 發(fā) ping 包。tcpdump 如果能收到 ICMP 請求幀說明轉發(fā)路徑已經(jīng)通了。如果只能收到廣播幀但收不到單播幀通常是 VLAN 設置里端口間的單播地址學習沒有打開需要查地址學習相關的寄存器。4.3 軟件轉發(fā)還是硬件轉發(fā)DSA 與普通 PHY 的選擇YT9215 在 Linux 里的角色定位會影響后續(xù)開發(fā)的復雜度是把整顆芯片當作一個 DSA switch 接入內核還是簡單地當作多路 PHY 來使用這是需要權衡的。DSA 方式能讓 YT9215 的各個端口在 Linux 里分別顯示為獨立的網(wǎng)絡接口比如 lan1、lan2、wan每個口可以獨立配置 IP、防火墻、流量策略內核的 bridge、VLAN 子系統(tǒng)天然適配。但 DSA 驅動要求芯片的寄存器接口符合 Linux 的 dsa_switch_ops 定義YT9215 如果沒有現(xiàn)成的 DSA 驅動就需要自己實現(xiàn)一套 port_vlan_add、port_stp_state_set 等回調函數(shù)工作量不小。另一種思路是把 YT9215 當作一個多端口的 PHY 組所有 LAN 口在硬件上直接做二層轉發(fā)CPU 端口收到的數(shù)據(jù)全部進 eth0再由軟件做路由或橋接。這種模式適合流量不需要在單個端口之間做硬件隔離的場景配置量小但缺點是 VLAN、速率控制、端口統(tǒng)計相關的功能都要自己去寫寄存器操作。我在網(wǎng)關類項目里通常會選擇 DSA 方式因為后續(xù)維護功能時內核的標準接口能省下大量代碼和時間。如果只是要快速出一個 Demo 驗證硬件選擇后者更快落地。5. 避坑調試 YT9215 時最容易翻車的五個點5.1 復位引腳釋放時序不對導致設備偶發(fā)失聯(lián)現(xiàn)象板子第一次上電能識別到 YT9215但軟件重啟之后設備經(jīng)常消失必須徹底斷電再上電才能恢復。有少數(shù)板卡表現(xiàn)為溫度降低后概率明顯上升看起來非常像硬件虛焊。原因YT9215 的復位釋放時序要求比普通 PHY 嚴格。系統(tǒng)復位時 GPIO 拉高的時間如果在電源電壓還沒完全穩(wěn)定的窗口內芯片內部邏輯可能進入不可恢復狀態(tài)PCIe link training 永遠失敗。軟件重啟不觸發(fā)大電容完全放電所以每次軟復位都在賭時序恰好正確。解決把復位控制從默認的 GPIO 操作改到硬件復位芯片上或者在設備樹里通過 pinctrl 控制復位引腳確保復位引腳默認拉低、系統(tǒng)啟動后期再拉高。更穩(wěn)妥的辦法是在驅動里加上一段延時操作從復位釋放到訪問芯片寄存器之間至少留 100ms 的等待時間。5.2 MDIO 讀到的 PHY ID 全是 0xFFFF現(xiàn)象mdio read 命令執(zhí)行正常但讀 PHY ID 寄存器返回的結果全部是 0xFFFF而且讀取沒有任何報錯提示。設備樹里無論怎么寫 reg 都無法讀到有效 ID。原因這個現(xiàn)象通常不是 MDIO 總線故障而是 MDIO 地址根本沒有映射到正確的 PHY。YT9215 有多個內部 PHY每個 PHY 都有一個獨立的 MDIO 地址地址由芯片外部引腳配置。讀 0xFFFF 意味著該地址上沒有任何 PHY 響應或者 MDIO 控制器時鐘配置太快芯片來不及在規(guī)定的時序窗口內回復。解決先用邏輯分析儀抓 MDIO 波形確認 MDC/MDIO 信號確實有活動。然后檢查設備樹里 MDIO clock 頻率許多 RK3568 方案的默認配置是 2.5MHz如果 YT9215 要求 2.0MHz 以下就會偶發(fā)讀不到數(shù)據(jù)。最后核對板卡原理圖上 PHYAD 引腳的連接是否存在浮空或者接錯的情況。5.3 CPU 端口能收到廣播卻收不到單播現(xiàn)象從 PC 連續(xù) ping 板卡 IPtcpdump 在 eth0 上只能看到 ARP 請求看不到 ICMP echo 幀。同一時刻PC 上的 ARP 表里板卡地址的狀態(tài)是 incomplete。原因這是典型的地址學習表問題。YT9215 的端口之間默認可能禁用 MAC 地址學習或者學習到的地址表項沒有自動老化刷新。CPU 端口的單播轉發(fā)依賴 FDB 表項而 FDB 表項需要交換芯片在收到源地址時更新。地址學習被關掉單播幀就無法反向查找端口只能被丟掉。解決找到地址學習控制寄存器顯式使能所有端口的學習功能。同時確認發(fā)貨缺省配置里 FDB 的靜態(tài)表項沒有被設置成錯誤的手動綁定。如果學習和老化都正常但依然丟單播查一下端口之間是否存在 STP 狀態(tài)位被設為 blocking也會產(chǎn)生同樣的癥狀。5.4 VLAN 標簽在 CPU 端口上未被剝離現(xiàn)象eth0 抓包能看到 VLAN ID 存在但板卡不能訪問外部網(wǎng)關。內部 LAN 口之間互通正常但只要涉及 CPU 收發(fā)的數(shù)據(jù)就全部異常tcpdump 里能看到大量的 vlan 100 標簽。原因交換芯片把從 LAN 口進入的 untagged 數(shù)據(jù)自動打上了 PVID轉發(fā)到 CPU 端口時幀完整保留了這個 tag。但 RK3568 的 stmmac 驅動默認沒有啟用 VLAN 處理接收到帶 tag 的幀后要么錯誤地提交到協(xié)議棧后被丟棄要么直接在硬件層過濾掉。解決配置 CPU 端口為 tag 剝離模式所有發(fā)往 CPU 的幀由芯片先去 tag。或者反過來在內核里把 eth0 的 vlan 接收功能顯式打開用 vlan 子接口去匹配對應的 VID。我通常推薦前者改動只涉及一組寄存器而且對系統(tǒng)路由的影響最小。5.5 吞吐量只有百兆但鏈路顯示 1000Mbps現(xiàn)象鏈路協(xié)商是千兆全雙工但通過 iperf3 測速穩(wěn)定在 95Mbps 左右而且無論換 PC 換網(wǎng)線結果都一樣。CPU 占用率不高網(wǎng)卡 ethtool 統(tǒng)計沒看到大量丟包。原因這種情況基本可以斷定是 SerDes 的工作模式配置問題。YT9215 的某些 SerDes 通道被復用成千兆接口時如果對應寄存器沒有設置成正確的速率匹配組物理層會在協(xié)商時撒謊報告千兆但實際上內部串口跑在百兆速率。另一個常見誘發(fā)點是 PCB 上的差分走線阻抗嚴重不匹配但一般硬件評審會擋掉這種問題軟件配置出錯更常見。解決把涉及 SerDes 速率匹配的寄存器全部重讀一遍重點看強制速率位和 auto-neg 配置位的組合是否合法。不要只依賴 ethtool 的協(xié)商結果用 iperf3 打流做實測通過不同速率下的吞吐對比來判斷 SerDes 配置是否生效。6. 把鏈路質量釘死iperf3 與 tcpdump 的組合驗證6.1 一次完整的鏈路驗證流程配置完成后單純 ping 通并不能說明系統(tǒng)能長期穩(wěn)定運行。我會用 iperf3 做雙向打流驗證同時配合 tcpdump 抓包確認轉發(fā)路徑中不存在隱藏的重傳或亂序。先做單方向的 TCP 打流再做雙向同時打流這一步能暴露交換芯片緩沖區(qū)在擁塞場景下的行為。rootboard:/# iperf3 -s rootboard:/# iperf3 -c 192.168.10.1 -t 60 -P 4在打流過程中tcpdump 的統(tǒng)計結果能清楚看到每個 5 秒窗口里的重傳數(shù)和亂序包數(shù)量。這個數(shù)值在空閑系統(tǒng)里應當接近零如果持續(xù)增長基本可以判斷交換芯片的隊列管理策略有問題或者 CPU 端口描述符緩沖區(qū)太小。通過 ethtool 查看網(wǎng)卡錯誤計數(shù)也能快速區(qū)分是 MAC 層問題還是交換芯片轉發(fā)能力問題。6.2 中斷綁核與系統(tǒng)級調優(yōu)的邊界RK3568 是四核處理器網(wǎng)絡中斷默認可能落在 CPU0。當批量轉發(fā)同時還有業(yè)務進程運行時CPU0 容易成為瓶頸。通過 /proc/irq 接口把網(wǎng)卡中斷綁到 CPU2 或 CPU3 上配合 RPSReceive Packet Steering進一步分散軟中斷負載。但要清醒認識一個邊界YT9215 的硬件轉發(fā)能力遠超 RK3568 的軟件處理能力在千兆模式下 CPU 是瓶頸而不是交換芯片所以系統(tǒng)調優(yōu)能改善的幅度是有限的。做完吞吐驗證和中斷綁定之后系統(tǒng)才算真正達到了交付狀態(tài)。我記得第一次在模擬項目X上把 YT9215 徹底調通那天結果反而沒有想象中興奮因為整個調試過程中反復出現(xiàn)的都是這些小問題——時序、地址、標簽剝離沒有一項涉及高深技術但每一項都足以卡住一兩天。從那以后我的習慣變了拿到板子先做硬件清單核對再寫驅動順序絕不調換。這套方法在后續(xù)幾個項目上一直沿用希望能幫到你。本文還有配套的精品資源點擊獲取 RK3568 + YT9215交換機芯片調試實戰(zhàn)：從硬件鏈路到千兆轉發(fā)
簡介面向嵌入式網(wǎng)絡設備開發(fā)場景這套源碼資源聚焦RK3568處理器與YT9215交換機芯片的驅動程序適配適用于從事Linux內核驅動、硬件接口調試的工程師學習參考。壓縮包共2個文件包含1個.c源文件和1個.h頭文件整體大小僅4KB其中.c源文件主要實現(xiàn)設備初始化、數(shù)據(jù)收發(fā)與中斷處理等驅動核心邏輯.h頭文件則定義驅動所需的結構體、常量與函數(shù)聲明兩者配合構成一個精簡可研究的驅動模塊。目前已有5129人瀏覽學習說明該主題在同類調試場景中有一定代表性。參照這兩個文件可梳理出從設備樹描述、驅動注冊到收發(fā)測試的完整思路。同時也能輔助定位硬件接口分析及驅動代碼編寫階段的常見問題為后續(xù)優(yōu)化與維護提供直接參考。1. RK3568 YT9215 在做什么從多網(wǎng)口需求到交換機芯片一塊 RK3568 的板子原生網(wǎng)口通常只有兩三個而一臺千兆交換機的需求往往起步就是四個千兆口起步有的還要帶光口或 PoE。與其換主控不如在 RK3568 的 PCIe 或 SGMII 接口上外掛一顆 YT9215 交換機芯片把網(wǎng)口數(shù)量一次性擴到五六個。方案聽起來順理成章但真正把板子拿到手開始調的人都知道這從來不是“插上就能用”的活。YT9215 不是普通 PHY它是一顆帶完整交換內核的芯片上電后默認配置可能連 CPU 端口都不通MDIO 讀不到 ID、寄存器寫不進去、內核里根本沒有對應驅動這才是常態(tài)。這篇文章要講的就是我在 RK3568 上把 YT9215 從頭調到能跑滿千兆的完整路徑適合正在做多網(wǎng)口網(wǎng)關、工業(yè)交換機或邊緣計算底板的開發(fā)者內容會一直寫到驗證工具和坑的解法。2. RK3568 與 YT9215 的硬件鏈路接口選型與上電檢查2.1 接口選型SGMII、RGMII 還是 PCIeRK3568 與 YT9215 之間的連接方式?jīng)Q定了我后續(xù)所有調試路徑的走向。常見的接法有三種SGMII、RGMII 和 PCIe。YT9215 這類交換芯片通常帶有多個 SerDes 通道通道可以被復用成 SGMII 接口連接主控也可以配置成 PCIe RC 模式或者作為 PCIe EP 被主控枚舉。硬件設計階段選哪種直接決定驅動方式是把它當普通 PHY 用還是當 PCIe 交換機用。我一般會優(yōu)先選 PCIe原因很實際。RK3568 原生 PCIe2.0 控制器打開后YT9215 會被識別成一個 PCIe 設備Linux 自帶的 switchtec 或者 mdio 觸達方式更靈活吞吐量上限也高SerDes 跑 5Gbps 跑滿千兆毫無壓力。如果板子上 PCIe 通道已經(jīng)被 NVMe 或 Wi-Fi 占用那就退一步用 SGMII把 YT9215 接到 RK3568 的 GMAC 控制器上讓 Linux 把它當作一個“帶內部交換功能的 PHY”。RGMII 是最后的選擇16bit 數(shù)據(jù)線布線要求高頻率跑不上 1000Mbps 以上速率只適合低成本的百兆場景。選型這件事上踩過的最大一個坑是把 PCIe 通道復用當成理所當然。RK3568 的 PCIe2.0 控制器和 SATA、USB3 之間本身就存在引腳復用硬件工程師如果沒在原理圖階段確認引腳的 mux 配置板子回來之后 PCIe 怎么都枚舉不到。軟件上可以通過修改 pinctrl 節(jié)點做嘗試但如果硬件上已經(jīng)走線錯誤系統(tǒng)端是無能為力的。2.2 上電前的硬件檢查先量電壓再做時鐘測量很多 YT9215 調不通的案子根因并不在軟件而是硬件細節(jié)不規(guī)范。YT9215 這類交換芯片比普通 PHY 復雜供電通常有 1.0V 核心電壓、1.8V 和 3.3V 三個域而且對上下電時序敏感。拿到板子第一步我習慣用示波器同時測三路電源的上升沿確認 1.0V 不要比 3.3V 先掉電。這個看似玄學的問題實際導致的典型故障是芯片經(jīng)常第一次能工作、重啟后失聯(lián)而且用萬用表量電壓全是正常的不加示波器根本發(fā)現(xiàn)不了。之后必須測量 YT9215 的時鐘輸入。25MHz 參考晶振是這顆芯片正常工作的基礎測的時候不要只看有沒有波形要關注頻率偏差超過 50ppm 的信號會影響 SerDes 的位同步表現(xiàn)為主控側鏈路反復 training 失敗。另外一個容易被忽略的是復位引腳的上電釋放時間YT9215 的復位釋放要晚于所有電源穩(wěn)定至少 10ms很多 ARM 板上的 GPIO 復位是系統(tǒng)起來之后才拉高導致第一次上電時芯片復位釋放時電源還沒完全穩(wěn)定后續(xù)初始化一團糟。硬件檢查做完后我習慣在 uboot 階段先做一個最基礎的探測。如果走的是 PCIe 連接在 uboot 命令行里直接執(zhí)行 pci enum然后查看設備樹中 PCIe 控制器是否識別到了設備。如果 VENDOR ID 讀出來是 0xFFFF說明物理鏈路就有問題這時候我會直接量 SerDes 的差分信號是否在輸出排除主控側 PCIe 控制器沒有正常 link up 的情況。Rockchip U-Boot pci enum Rockchip U-Boot pci 0執(zhí)行后如果沒有任何設備號顯示把 dmesg 打開看 PCIe 控制器報錯信息重點找 PHY PLL lock 失敗和 LTSSM 狀態(tài)的打印。LTSSM 停在 Detect 狀態(tài)基本就是時鐘或復位問題停在 Configuration 之前的狀態(tài)則大概率是 SerDes 通道配置不一致。2.3 用 devmem 驗證 YT9215 是否在總線上可見在 Linux 系統(tǒng)起來之后第一件事不是急著配置 switch而是確認 YT9215 在地址空間里可訪問。PCIe 連接的情況下查看 /sys/bus/pci/devices/ 目錄下多沒多設備再用 setpci 看配置空間里的 VENDOR ID 和 DEVICE ID。rootboard:/# ls /sys/bus/pci/devices/ 0000:01:00.0 rootboard:/# setpci -s 01:00.0 vendor_id如果讀到 ID 正常說明物理鏈路已經(jīng)打通了。這時候直接讀寫 YT9215 的寄存器空間還是借道 PCIe config space 或者是 BAR 空間映射取決于這顆芯片的設計。常見做法是 YT9215 會提供一塊內部寄存器映射通過 PCIe BAR0 窗口暴露給主控。可以用 devmem 把 BAR0 的地址映射出來直接讀芯片的 ID 寄存器驗證訪問通路。rootboard:/# setpci -s 01:00.0 base-address-0拿到 BAR0 的物理地址之后用 devmem 讀芯片內部基地址偏移處的 chip ID 寄存器。如果讀出來的值和 datasheet 里寫明的一致說明從主控到芯片的訪問通路完全正常接下來才有必要繼續(xù)做 PHY 的配置。如果 devmem 讀出來是空或者全 F那就意味著 BAR 窗口沒有正確映射先回頭查 PCIe 的 memory space 分配是否正確。3. 把 MDIO 和 PHY 狀態(tài)打通最小驅動加載路徑3.1 最小驅動加載路徑從設備樹描述一張外掛設備YT9215 在 Linux 下沒有現(xiàn)成驅動的概率很高內核 mainline 未必會收錄這顆芯片的完整 switch 驅動。常見做法是把它當作普通的 MDIO 設備來描述讓 Linux 的 MDIO 總線框架管理起來再由用戶態(tài)工具直接操作寄存器完成核心的配置工作。在設備樹里我一般會在 GMAC 節(jié)點下面掛一個 mdio 子節(jié)點然后描述這顆 PHY。這種描述方式的最大價值在于讓內核的網(wǎng)絡子系統(tǒng)認為這個端口上連著一個 PHY從而 eth0 這個網(wǎng)絡設備能正常 up后續(xù) MDIO 的訪問路徑也是通的。設備樹描述示例如下gmac0 { status okay; phy-mode sgmii; mdio0: mdio { compatible snps,dwmac-mdio; #address-cells 1; #size-cells 0; switch_phy: ethernet-phy1 { reg 1; compatible ethernet-phy-id1234.5678; }; }; };這里的 phy-mode 根據(jù)實際硬件連接方式填寫如果走的是 PCIe 連接就不需要這個描述直接用 PCIe 驅動去枚舉。ethernet-phy1中的 reg 是 YT9215 在 MDIO 總線上的物理地址這個地址取決于硬件上 PHYAD 引腳的上下拉配置不能隨意修改否則驅動會 probe 不到設備。compatible里的 ID 號要和 YT9215 的實際 PHY ID 對應起來大部分人這一步會卡住因為芯片里的 PHY ID 和 datasheet 上寫的不完全一致最穩(wěn)妥的辦法是先用 MDIO 工具讀寄存器把 ID 算出來再填。設備樹配好之后內核啟動日志里如果能看到 MDIO bus 上發(fā)現(xiàn)了一個 PHY說明內核已經(jīng)識別到設備。這時候 eth0 可能還沒有 IP但鏈路狀態(tài)應該可以從 down 變成 up。當然YT9215 有多組 SerDes 和多哥 PHY 端口需要在 mdio 節(jié)點下重復掛多端口描述后續(xù)每個對外網(wǎng)口才能有對應的 net_device。3.2 用 mdio-tools 直接驗證 PHY 寄存器內核識別之后不要急著寫驅動邏輯先用 mdio-tools 手動讀一遍寄存器。mdio-tools 是 mdio 讀寫工具集的常見實現(xiàn)一般在 buildroot 里勾選就能編譯進去。如果系統(tǒng)里沒有直接用 busybox 自帶的 mdio 命令也可以只是功能略少。我用的是 mdio-tools 的 mdio read 和 mdio write命令直觀適合一步一步踩。先讀 PHY ID 寄存器組標準 PHY 的 ID 寄存器的地址是 2 和 3。執(zhí)行命令之后把兩個寄存器讀取的值拼起來得到的是一個 32 位 PHY ID。rootboard:/# mdio read eth0 1 2 0x1234 rootboard:/# mdio read eth0 1 3 0x5678讀出來的 ID 值和 datasheet 里標準的 OUI 對照確認這顆 PHY 在內核的 PHY ID 列表里有沒有被定義。通常 YT9215 這種交換芯片內部的 PHY 核心 ID 是已知的但也不排除芯片廠家用的自定義 ID這種情況下要把 compatible 換成實際讀到的數(shù)字否則驅動 probe 不了。之后讀寄存器 0BMCR和寄存器 1BMSR看它們的默認值是否和 reset 后的狀態(tài)一致。rootboard:/# mdio read eth0 1 0 0x1140 rootboard:/# mdio read eth0 1 1 0x796dBMSR 寄存器里的 bit5 表示 autoneg completebit2 表示 link status。如果讀出來 link 狀態(tài)位為 0表示物理層沒有檢測到對端這并不一定是壞事因為 YT9215 的某些 SerDes 端口在默認配置下是處于低功耗或未啟用狀態(tài)的。此時可以嘗試手動配置 BMCR 寄存器強制 1000Mbps 全雙工再讀 BMSR 確認鏈路是否能起來。3.3 驅動加載失敗時的三處關鍵日志如果 mdio read 命令執(zhí)行不了或者 PHY ID 讀出來全是 F大概率是內核網(wǎng)絡設備沒有真正起來。這時候我會按順序排查三處日志。首先是 dmesg 里和 stmmac 或 dwmac 相關的行。RK3568 的 GMAC 驅動是 stmmac 框架日志里會打印 phy mode、MDIO 時鐘頻率、初始化狀態(tài)。如果打印顯示 MDIO 時鐘配置失敗檢查設備樹里 mdio 子節(jié)點的時鐘屬性通常需要顯式指定 MDC 的頻率上限否則總線的時序和 YT9215 不匹配。其次是 /sys/class/net 目錄下有沒有出現(xiàn)對應的 ethX 設備。如果設備樹里 GMAC 節(jié)點狀態(tài)沒有改為 okay整個 MAC 控制器都不會 probe自然沒有網(wǎng)絡接口。這個低級問題出現(xiàn)的頻率比想象中高很多時候是設備樹 overlay 沒有正確加載。最后是 interrupts 相關的報錯。YT9215 的 interrupt 引腳如果接到 RK3568 的 GPIO 上設備樹里必須配置正確的中斷號和觸發(fā)方式。中斷配置錯了表現(xiàn)為鏈路狀態(tài)變化時內核不感知即使物理連接恢復了網(wǎng)絡接口依舊顯示 down這種問題非常容易讓人困惑看起來像硬件壞了實際只是內核沒有收到中斷。4. 讓數(shù)據(jù)從網(wǎng)口真正走到 CPUPCS 環(huán)回與轉發(fā)配置4.1 先做 PCS 環(huán)回把物理鏈路的鍋關掉當 PHY 層已經(jīng)能正常 link但 ping 不通的時候先別急著查轉發(fā)邏輯在第一層做環(huán)回測試是最快的隔離手段。YT9215 這類芯片內部支持 PCS 層的環(huán)回把從主控 MAC 發(fā)出的數(shù)據(jù)在芯片內部直接環(huán)回到 MAC 接收側。這一步通過 MDIO 寫一個特定寄存器不需要外部接網(wǎng)線就能驗證主控到芯片之間的通路是否正常。rootboard:/# mdio write eth0 1 0x8000 0x0040這個操作的實質是設置 MII 控制寄存器里的 loopback 位。配置完之后從 eth0 ping 一個指定 IP 地址比如 192.168.1.1如果在環(huán)回模式下能 ping 通說明以太網(wǎng) MAC 到 YT9215 的 SerDes 通路是完好的。如果 ping 不通問題就出在 RK3568 的 GMAC 控制器配置或者 DMA 描述符鏈上沒必要去查后續(xù)的交換邏輯。PCS 環(huán)回測試通過后立即把環(huán)回位清除避免后面調試時數(shù)據(jù)平面被干擾。環(huán)回測試的另一個變種是 MAC 層的環(huán)回通過 RK3568 的 GMAC 控制器本身的 loopback 功能來做。兩者可以結合使用出現(xiàn)問題時能快速確認是主控側的問題還是 YT9215 側的問題。我在實際調試中最怕的就是這兩層問題交織在一起不做好環(huán)回隔離后面查 VLAN 和轉發(fā)配置時很容易被底層鏈路問題誤導。4.2 轉發(fā)路徑與 CPU 收包寄存器級最小配置YT9215 默認狀態(tài)下各端口之間未必自動轉發(fā)CPU 端口更是需要顯式配置。要把數(shù)據(jù)從某個 LAN 口送到主控的內核協(xié)議棧必須做兩件事讓 CPU 端口成為交換矩陣的成員端口并且配置 VLAN 和端口成員關系。YT9215 的寄存器空間里有一組端口控制寄存器我用 MDIO 寫的方式逐一配置端口使能和端口模式。常見配置是把所有端口設為千兆全雙工同時使能 802.1Q 的 VLAN 感知功能。最小化的配置是把所有 LAN 口劃入同一個 VLAN ID比如 VLAN 1CPU 端口也加入這個 VLAN這樣從 LAN 口收到的 untagged 數(shù)據(jù)幀會被打上 VLAN 1 的標簽并轉發(fā)到 CPU 端口。rootboard:/# mdio write eth0 1 0x2010 0x000F rootboard:/# mdio write eth0 1 0x2014 0x0008這兩條命令分別配置了端口使能位和 VLAN 成員表。寄存器地址的偏移量每顆芯片略有差異我這里寫的地址是 YT9215 一類芯片的常見布局實際使用時要以 datasheet 的寄存器偏移為準。這一步最容易翻車的地方就是把 CPU 端口的標簽位配錯。有些交換芯片要求 CPU 端口收上來的幀帶一個自定義的 tag不配置這個 tag 識別規(guī)則CPU 收到幀后會被網(wǎng)卡驅動當成錯誤幀丟掉。配置完成后用 tcpdump 在 eth0 上抓包從某個 LAN 口接一臺 PC 發(fā) ping 包。tcpdump 如果能收到 ICMP 請求幀說明轉發(fā)路徑已經(jīng)通了。如果只能收到廣播幀但收不到單播幀通常是 VLAN 設置里端口間的單播地址學習沒有打開需要查地址學習相關的寄存器。4.3 軟件轉發(fā)還是硬件轉發(fā)DSA 與普通 PHY 的選擇YT9215 在 Linux 里的角色定位會影響后續(xù)開發(fā)的復雜度是把整顆芯片當作一個 DSA switch 接入內核還是簡單地當作多路 PHY 來使用這是需要權衡的。DSA 方式能讓 YT9215 的各個端口在 Linux 里分別顯示為獨立的網(wǎng)絡接口比如 lan1、lan2、wan每個口可以獨立配置 IP、防火墻、流量策略內核的 bridge、VLAN 子系統(tǒng)天然適配。但 DSA 驅動要求芯片的寄存器接口符合 Linux 的 dsa_switch_ops 定義YT9215 如果沒有現(xiàn)成的 DSA 驅動就需要自己實現(xiàn)一套 port_vlan_add、port_stp_state_set 等回調函數(shù)工作量不小。另一種思路是把 YT9215 當作一個多端口的 PHY 組所有 LAN 口在硬件上直接做二層轉發(fā)CPU 端口收到的數(shù)據(jù)全部進 eth0再由軟件做路由或橋接。這種模式適合流量不需要在單個端口之間做硬件隔離的場景配置量小但缺點是 VLAN、速率控制、端口統(tǒng)計相關的功能都要自己去寫寄存器操作。我在網(wǎng)關類項目里通常會選擇 DSA 方式因為后續(xù)維護功能時內核的標準接口能省下大量代碼和時間。如果只是要快速出一個 Demo 驗證硬件選擇后者更快落地。5. 避坑調試 YT9215 時最容易翻車的五個點5.1 復位引腳釋放時序不對導致設備偶發(fā)失聯(lián)現(xiàn)象板子第一次上電能識別到 YT9215但軟件重啟之后設備經(jīng)常消失必須徹底斷電再上電才能恢復。有少數(shù)板卡表現(xiàn)為溫度降低后概率明顯上升看起來非常像硬件虛焊。原因YT9215 的復位釋放時序要求比普通 PHY 嚴格。系統(tǒng)復位時 GPIO 拉高的時間如果在電源電壓還沒完全穩(wěn)定的窗口內芯片內部邏輯可能進入不可恢復狀態(tài)PCIe link training 永遠失敗。軟件重啟不觸發(fā)大電容完全放電所以每次軟復位都在賭時序恰好正確。解決把復位控制從默認的 GPIO 操作改到硬件復位芯片上或者在設備樹里通過 pinctrl 控制復位引腳確保復位引腳默認拉低、系統(tǒng)啟動后期再拉高。更穩(wěn)妥的辦法是在驅動里加上一段延時操作從復位釋放到訪問芯片寄存器之間至少留 100ms 的等待時間。5.2 MDIO 讀到的 PHY ID 全是 0xFFFF現(xiàn)象mdio read 命令執(zhí)行正常但讀 PHY ID 寄存器返回的結果全部是 0xFFFF而且讀取沒有任何報錯提示。設備樹里無論怎么寫 reg 都無法讀到有效 ID。原因這個現(xiàn)象通常不是 MDIO 總線故障而是 MDIO 地址根本沒有映射到正確的 PHY。YT9215 有多個內部 PHY每個 PHY 都有一個獨立的 MDIO 地址地址由芯片外部引腳配置。讀 0xFFFF 意味著該地址上沒有任何 PHY 響應或者 MDIO 控制器時鐘配置太快芯片來不及在規(guī)定的時序窗口內回復。解決先用邏輯分析儀抓 MDIO 波形確認 MDC/MDIO 信號確實有活動。然后檢查設備樹里 MDIO clock 頻率許多 RK3568 方案的默認配置是 2.5MHz如果 YT9215 要求 2.0MHz 以下就會偶發(fā)讀不到數(shù)據(jù)。最后核對板卡原理圖上 PHYAD 引腳的連接是否存在浮空或者接錯的情況。5.3 CPU 端口能收到廣播卻收不到單播現(xiàn)象從 PC 連續(xù) ping 板卡 IPtcpdump 在 eth0 上只能看到 ARP 請求看不到 ICMP echo 幀。同一時刻PC 上的 ARP 表里板卡地址的狀態(tài)是 incomplete。原因這是典型的地址學習表問題。YT9215 的端口之間默認可能禁用 MAC 地址學習或者學習到的地址表項沒有自動老化刷新。CPU 端口的單播轉發(fā)依賴 FDB 表項而 FDB 表項需要交換芯片在收到源地址時更新。地址學習被關掉單播幀就無法反向查找端口只能被丟掉。解決找到地址學習控制寄存器顯式使能所有端口的學習功能。同時確認發(fā)貨缺省配置里 FDB 的靜態(tài)表項沒有被設置成錯誤的手動綁定。如果學習和老化都正常但依然丟單播查一下端口之間是否存在 STP 狀態(tài)位被設為 blocking也會產(chǎn)生同樣的癥狀。5.4 VLAN 標簽在 CPU 端口上未被剝離現(xiàn)象eth0 抓包能看到 VLAN ID 存在但板卡不能訪問外部網(wǎng)關。內部 LAN 口之間互通正常但只要涉及 CPU 收發(fā)的數(shù)據(jù)就全部異常tcpdump 里能看到大量的 vlan 100 標簽。原因交換芯片把從 LAN 口進入的 untagged 數(shù)據(jù)自動打上了 PVID轉發(fā)到 CPU 端口時幀完整保留了這個 tag。但 RK3568 的 stmmac 驅動默認沒有啟用 VLAN 處理接收到帶 tag 的幀后要么錯誤地提交到協(xié)議棧后被丟棄要么直接在硬件層過濾掉。解決配置 CPU 端口為 tag 剝離模式所有發(fā)往 CPU 的幀由芯片先去 tag。或者反過來在內核里把 eth0 的 vlan 接收功能顯式打開用 vlan 子接口去匹配對應的 VID。我通常推薦前者改動只涉及一組寄存器而且對系統(tǒng)路由的影響最小。5.5 吞吐量只有百兆但鏈路顯示 1000Mbps現(xiàn)象鏈路協(xié)商是千兆全雙工但通過 iperf3 測速穩(wěn)定在 95Mbps 左右而且無論換 PC 換網(wǎng)線結果都一樣。CPU 占用率不高網(wǎng)卡 ethtool 統(tǒng)計沒看到大量丟包。原因這種情況基本可以斷定是 SerDes 的工作模式配置問題。YT9215 的某些 SerDes 通道被復用成千兆接口時如果對應寄存器沒有設置成正確的速率匹配組物理層會在協(xié)商時撒謊報告千兆但實際上內部串口跑在百兆速率。另一個常見誘發(fā)點是 PCB 上的差分走線阻抗嚴重不匹配但一般硬件評審會擋掉這種問題軟件配置出錯更常見。解決把涉及 SerDes 速率匹配的寄存器全部重讀一遍重點看強制速率位和 auto-neg 配置位的組合是否合法。不要只依賴 ethtool 的協(xié)商結果用 iperf3 打流做實測通過不同速率下的吞吐對比來判斷 SerDes 配置是否生效。6. 把鏈路質量釘死iperf3 與 tcpdump 的組合驗證6.1 一次完整的鏈路驗證流程配置完成后單純 ping 通并不能說明系統(tǒng)能長期穩(wěn)定運行。我會用 iperf3 做雙向打流驗證同時配合 tcpdump 抓包確認轉發(fā)路徑中不存在隱藏的重傳或亂序。先做單方向的 TCP 打流再做雙向同時打流這一步能暴露交換芯片緩沖區(qū)在擁塞場景下的行為。rootboard:/# iperf3 -s rootboard:/# iperf3 -c 192.168.10.1 -t 60 -P 4在打流過程中tcpdump 的統(tǒng)計結果能清楚看到每個 5 秒窗口里的重傳數(shù)和亂序包數(shù)量。這個數(shù)值在空閑系統(tǒng)里應當接近零如果持續(xù)增長基本可以判斷交換芯片的隊列管理策略有問題或者 CPU 端口描述符緩沖區(qū)太小。通過 ethtool 查看網(wǎng)卡錯誤計數(shù)也能快速區(qū)分是 MAC 層問題還是交換芯片轉發(fā)能力問題。6.2 中斷綁核與系統(tǒng)級調優(yōu)的邊界RK3568 是四核處理器網(wǎng)絡中斷默認可能落在 CPU0。當批量轉發(fā)同時還有業(yè)務進程運行時CPU0 容易成為瓶頸。通過 /proc/irq 接口把網(wǎng)卡中斷綁到 CPU2 或 CPU3 上配合 RPSReceive Packet Steering進一步分散軟中斷負載。但要清醒認識一個邊界YT9215 的硬件轉發(fā)能力遠超 RK3568 的軟件處理能力在千兆模式下 CPU 是瓶頸而不是交換芯片所以系統(tǒng)調優(yōu)能改善的幅度是有限的。做完吞吐驗證和中斷綁定之后系統(tǒng)才算真正達到了交付狀態(tài)。我記得第一次在模擬項目X上把 YT9215 徹底調通那天結果反而沒有想象中興奮因為整個調試過程中反復出現(xiàn)的都是這些小問題——時序、地址、標簽剝離沒有一項涉及高深技術但每一項都足以卡住一兩天。從那以后我的習慣變了拿到板子先做硬件清單核對再寫驅動順序絕不調換。這套方法在后續(xù)幾個項目上一直沿用希望能幫到你。本文還有配套的精品資源點擊獲取