- 論壇徽章:
- 0
|
SDK版本:sdk-all-5.6.6 操作系統(tǒng)版本:tile-linux 2.6.26 該工作沒(méi)有什么現(xiàn)成的文檔進(jìn)行參考,主要還是在實(shí)際的SDK移植工作中進(jìn)行經(jīng)驗(yàn)積累,認(rèn)真閱讀SDK源代碼,從中獲得一些Broadcom文檔中沒(méi)有提到過(guò)的軟件流程和操作。 一.移植過(guò)程中sdk源代碼主要修改的地方有: 1. 將system/bde/linux/kernel/linux-kernel-bde.c文件中無(wú)法解析的系統(tǒng)導(dǎo)出符號(hào)如virt_to_bus和bus_to_virt用tile-linux系統(tǒng)代碼替換,因?yàn)槲覀冞x擇的硬件體系make文件來(lái)自與raptor體系,所有需要注銷掉raptor體系中使用的MIPS CPU相關(guān)的系統(tǒng)定義參數(shù)如 2. 將sdk中所有與pcie bar內(nèi)存空間(主要是base_address相關(guān)的地址)的讀寫(xiě)操作替換為tilelinux要求的tile_readl和tile_wirtel函數(shù)接口,因?yàn)閠ilepro36最pcie內(nèi)存空間讀寫(xiě)不允許直接對(duì)內(nèi)存地址進(jìn)行讀寫(xiě)(通過(guò)指針的方式)。 其他沒(méi)有修改的地方,可見(jiàn)broadcom的sdk軟件對(duì)系統(tǒng)移植所作的工作非常成功,極大的方便了用戶的移植,缺點(diǎn)只是提供的文檔不夠充分,要求能夠從源代碼中快速定位并解決問(wèn)題。
二.加載BCM shell 該過(guò)程中出現(xiàn)了小小的插曲,剛開(kāi)始時(shí)進(jìn)行了一中的工作后,發(fā)現(xiàn)每次加載bcm.user.proxy程序后都會(huì)出現(xiàn)反復(fù)打印參數(shù)無(wú)法解析的錯(cuò)誤信息直到死機(jī),或者是進(jìn)行shell了但ps查看端口狀態(tài)出現(xiàn)死機(jī)的現(xiàn)象。聽(tīng)取總工的意見(jiàn)使用一個(gè)tile核運(yùn)行tile-linux,防止由于SMP的原因造成模塊死機(jī),修改后BCM shell運(yùn)行穩(wěn)定,或許是由于sdk中的SMP及鎖機(jī)制與特殊的tile-linux不符造成的,原因待查。但每次上電硬件重啟后首次加載bcm模塊還會(huì)出現(xiàn)反復(fù)打印參數(shù)無(wú)法解析的錯(cuò)誤,但帶電手動(dòng)復(fù)位或中斷加載過(guò)程重新加載模塊則模塊運(yùn)行正常?傊瑔魏诉\(yùn)行后,ps能正確顯示link up的鏈路端口,以及查看各端口收發(fā)數(shù)據(jù)報(bào)數(shù)量,操作MII對(duì)phy寄存器進(jìn)行讀寫(xiě)。
補(bǔ)充:關(guān)于bcm-shell不能在開(kāi)啟多個(gè)tile時(shí)執(zhí)行問(wèn)題的解決。 開(kāi)啟多個(gè)tile時(shí),每次啟動(dòng)時(shí)都發(fā)現(xiàn)linux-kernel-bde.c文件_dma_segment_alloc函數(shù)中,執(zhí)行語(yǔ)句MEM_MAP_RESERVE(VIRT_TO_PAGE(page_addr));時(shí)出現(xiàn)系統(tǒng)crash,簡(jiǎn)單的注銷掉即可屏蔽問(wèn)題。
三.調(diào)試鏈路 mpcb使用bcm5461與tile的gbe0接口連接,協(xié)議是SerDes(switch)->RGMII(gbe0),phy工作在fiber模式 ; 使用bcm5464與amc子卡arm以太網(wǎng)接口、amc子卡fpga以太網(wǎng)接口以及后插卡以太網(wǎng)接口進(jìn)行連接,協(xié)議是SGMII(switch)->1000base-T(以太網(wǎng)接口),phy工作在copper模式; 5464為4個(gè)5461的集合芯片,二者功能相同,需要注意的是對(duì)0x18,0x1c等shadow register的讀寫(xiě)操作方式,不同之處是5464的phy地址以端口0開(kāi)始逐漸增1。
之前鏈路無(wú)法ping通一直懷疑是phy芯片沒(méi)有正確的配置。但最終的結(jié)論是只要硬件管腳設(shè)置到正確的工作模式,軟件不需要配置任何phy寄存器,只需要檢測(cè)自協(xié)商情況下的link up位等待鏈路建立。
5461遇到的情況及解決的方法是: gbe0發(fā)送的報(bào)首先在交換芯片端口上可以查看到,甚至在外部pc機(jī)也可以通過(guò)抓報(bào)工作正確識(shí)別出,但gbe0接收到的數(shù)據(jù)包使用交叉編譯后的工具tcpdump在tile上抓取,發(fā)現(xiàn)每次受到的數(shù)據(jù)報(bào)會(huì)有比特隨機(jī)變化。 原因是由于tilepro36 gbe0端口的數(shù)據(jù)接收時(shí)鐘線RXC需要對(duì)數(shù)據(jù)接收線RXD要求有時(shí)間上的延時(shí),但5461對(duì)該延時(shí)控制可以在copper模式下通過(guò)設(shè)置寄存器做到,但在fiber模式下5461不支持該延時(shí)操作,所以只能通過(guò)硬件電路繞線的方式人工增加所需要的延時(shí)量。
5464遇到的情況及解決的方法是: 5461是通過(guò)tile的MII接口進(jìn)行讀寫(xiě),而5464是通過(guò)交換芯片的MII接口進(jìn)行讀寫(xiě)的,通過(guò)BCM shell phy命令手動(dòng)讀寫(xiě)5464各寄存器發(fā)現(xiàn)配置及狀態(tài)正常,只是BCM shell在掃描的時(shí)候把本來(lái)接在ge18~ge21的1個(gè)5464(但該四個(gè)端口都應(yīng)該顯示為5464)掃描成了ge0~ge2三個(gè)端口的三個(gè)5464,缺少了一個(gè)5464通道。 認(rèn)真查看sdk代碼發(fā)現(xiàn)源代碼在進(jìn)行各端口port對(duì)應(yīng)的phy掃描時(shí),內(nèi)部存在一個(gè)定義好的每個(gè)port應(yīng)該掃描的phy地址表格,當(dāng)選擇外部phy掃描時(shí),從ge0(port2)到hg3(port29),對(duì)應(yīng)的phy地址從0x1到0x1d,所以在沒(méi)有指定kconfig_list參數(shù)字符串的情況下,默認(rèn)ge0端口從phy地址1查起,所以只能掃描到3個(gè)phy通道,而且還是從不正確的port2(ge0)開(kāi)始的。 可以通過(guò)函數(shù)kconfig_set("port_phy_addr.port21.BCM56334_A0", "0x01")語(yǔ)句人工指定mpcb對(duì)應(yīng)端口的phy地址。 注:BCM shell中的ge0并不對(duì)應(yīng)port0,因?yàn)閜ort0和port1用于芯片內(nèi)部通道使用,所有g(shù)e0為port2開(kāi)始。
10G端口遇到的情況及解決方法是: mpcb的10G端口xgbe0與交換芯片hg0端口進(jìn)行直連。 現(xiàn)象是xgbe0能夠發(fā)送數(shù)據(jù)報(bào)到交換芯片的對(duì)應(yīng)端口,但在BCM shell和pc機(jī)端都無(wú)法抓取不到數(shù)據(jù)報(bào),同時(shí)xgbe0端口也無(wú)接收到數(shù)據(jù)的信息顯示。 解決方法是: 首先通過(guò)查看bcm shell保證經(jīng)過(guò)交換芯片的數(shù)據(jù)報(bào)沒(méi)有錯(cuò)誤,尤其是CRC錯(cuò)誤; 其次broadcom為了實(shí)現(xiàn)級(jí)聯(lián)將10G傳輸?shù)臉?biāo)準(zhǔn)以太網(wǎng)報(bào)改裝成私有的HiGig+或HiGig2形式,該私有以太網(wǎng)報(bào)無(wú)法被正常的網(wǎng)絡(luò)協(xié)議棧設(shè)置所接收,所以會(huì)造成數(shù)據(jù)報(bào)顯示錯(cuò)誤或無(wú)法接收和抓取到數(shù)據(jù)報(bào); 修改方法是在bcm shell中使用命令port 26 encap=ieee其中port26為hg0,將默認(rèn)的10G Higig端口改為標(biāo)準(zhǔn)的以太網(wǎng)10G接口;或者是修改多核處理器端寄存器配置以適應(yīng)HiGig私有報(bào)格式。
|
|