1. 為什么一塊PCI9054老卡還在往Win7上搬手里還壓著一批PCI9054的數(shù)據(jù)采集卡上位機(jī)軟件和后臺(tái)數(shù)據(jù)庫卻非要往Windows 7上遷——這個(gè)場景我相信做工業(yè)設(shè)備的老工程師都不陌生。PCI9054這顆PCI橋芯片本身不復(fù)雜麻煩在它服役的那個(gè)年代配套的PCI9x5x驅(qū)動(dòng)工程還是靠著XP/2003的WDM技術(shù)棧在跑。系統(tǒng)一換設(shè)備管理器里立刻冒出一堆“PCI Device”未知設(shè)備廠商技術(shù)支持早就斷檔給的驅(qū)動(dòng)光盤還停留在32位時(shí)代。我這邊當(dāng)時(shí)接到的需求很直白板卡硬件不動(dòng)上位機(jī)采集程序盡量不改只要讓板卡在Win732位和64位都得覆蓋下穩(wěn)定跑起來。拿到原廠SDK翻了半天才發(fā)現(xiàn)所謂“PCI9x5x驅(qū)動(dòng)”其實(shí)是覆蓋9050/9052/9054/9056這一整個(gè)905x系列的原廠驅(qū)動(dòng)框架包含設(shè)備驅(qū)動(dòng)sys文件、應(yīng)用層API動(dòng)態(tài)庫和配置工具三塊。也就是說我們真正要?jiǎng)拥闹皇堑讓幽且粋€(gè)驅(qū)動(dòng)工程上層調(diào)用接口基本不用碰。動(dòng)手之前先算一筆賬到底走哪條路劃算。我把當(dāng)時(shí)列的方案對照表留在這兒很多團(tuán)隊(duì)卡在第一步就是因?yàn)檫x錯(cuò)了方向遷移路線硬件投入開發(fā)周期技術(shù)風(fēng)險(xiǎn)上位機(jī)改動(dòng)量換新一代PCIe采集卡高單卡數(shù)千元2-3周低但工程改造大大接口和寄存器全變虛擬機(jī)XPPCI直通零1周高實(shí)時(shí)性和直通兼容差無但性能損失明顯移植原廠PCI9x5x驅(qū)動(dòng)零3-4周中集中在驅(qū)動(dòng)層幾乎為零完全重新寫一個(gè)WDM驅(qū)動(dòng)零8周以上高DMA和中斷全要自己調(diào)需要封裝新API最后我們選了第三條路基于原廠SDK做驅(qū)動(dòng)移植。原因很樸素——9054的本地總線時(shí)序、EEPROM配置、DMA描述符這塊邏輯已經(jīng)在原廠驅(qū)動(dòng)里驗(yàn)證過一輪我們重新發(fā)明的意義不大。真正要解決的是讓它能在Win7的PnP、電源管理和64位尋址規(guī)則下活下來。選擇這條路還有一個(gè)隱藏前提得先確認(rèn)減壓帽EEPROM的配置還健康。9054的上電配置全靠EEPROM我用的是93CS56如果板子上的EEPROM配置損壞或者被刷成了Unknown模式后續(xù)驅(qū)動(dòng)就算移植成功板卡資源也映射不對。所以開工第一步建議先接上原廠監(jiān)控軟件讀一遍BAR地址和本地寄存器配置確認(rèn)硬件層沒丟東西再談驅(qū)動(dòng)代碼。2. PCI9x5x驅(qū)動(dòng)工程內(nèi)部結(jié)構(gòu)拆解拿到原廠SDK之后別急著改代碼先把目錄結(jié)構(gòu)吃透。整個(gè)PCI9x5x驅(qū)動(dòng)工程雖然名字帶“驅(qū)動(dòng)”但里面其實(shí)是三個(gè)層次的東西內(nèi)核驅(qū)動(dòng)層編譯出來就是sys文件負(fù)責(zé)枚舉PCI設(shè)備、處理IRP、做物理地址映射、管理DMA和中斷。這一層是移植的主戰(zhàn)場。API封裝層編譯成DLL把DeviceIoControl的細(xì)節(jié)封裝成類似P9054_Open、P9054_ReadBlock這種函數(shù)。上層硬件工程師基本都在這個(gè)層面寫代碼只要DLL的導(dǎo)出函數(shù)名不變上位機(jī)程序可以原封不動(dòng)繼續(xù)用。配置工具層讀寫EEPROM、查看PCI配置空間和本地寄存器。這東西和驅(qū)動(dòng)行為強(qiáng)相關(guān)后期排查問題的時(shí)候離不開它。理解這個(gè)三層結(jié)構(gòu)很重要因?yàn)槟愫苋菀讜?huì)被“原廠驅(qū)動(dòng)沒法在Win7用”這句話誤導(dǎo)以為整包都要重寫。我在實(shí)際項(xiàng)目里的判斷是DLL和應(yīng)用層只要沒有用到XP特有的API比如老版本DirectX、Win7不兼容的CreateFile參數(shù)調(diào)用幾乎不用改核心沉在內(nèi)核驅(qū)動(dòng)對IRP_MJ_PNP、IRP_MJ_DEVICE_CONTROL和中斷DMA的處理邏輯上。打開原廠驅(qū)動(dòng)工程WDM框架的骨架其實(shí)還挺規(guī)整NTSTATUS DriverEntry(IN PDRIVER_OBJECT DriverObject, IN PUNICODE_STRING RegistryPath) { // 注冊各個(gè)分發(fā)例程 DriverObject-MajorFunction[IRP_MJ_CREATE] P905xCreate; DriverObject-MajorFunction[IRP_MJ_CLOSE] P905xClose; DriverObject-MajorFunction[IRP_MJ_DEVICE_CONTROL] P905xDeviceControl; DriverObject-MajorFunction[IRP_MJ_PNP] P905xDispatchPnp; DriverObject-MajorFunction[IRP_MJ_READ] P905xDispatchRead; DriverObject-DriverUnload P905xUnload; return STATUS_SUCCESS; }注意PCI9x5x這個(gè)系列驅(qū)動(dòng)比較特別它把905x多個(gè)芯片的差異收在了同一個(gè)sys里通過PCI配置空間的DeviceID判斷具體是9054還是9056。這個(gè)做法移植時(shí)反而省事——只要板卡的硬件ID寫在INF里驅(qū)動(dòng)加載時(shí)能夠走到AddDevice硬件類型是自己識(shí)別出來的。硬件寄存器映射上PCI9054對外的BAR分工也需要提前記牢BAR0PCI配置寄存器包括PCI命令、狀態(tài)、中斷BAR1本地配置寄存器Local Configuration RegistersLCRBAR2、BAR3本地總線映射空間取決于Local Bus設(shè)置為Memory還是IO空間驅(qū)動(dòng)在StartDevice階段做的最重要一件事就是把BAR1物理地址通過MmMapIoSpace映射成虛擬地址然后后續(xù)所有9054內(nèi)部控制字的讀寫都在這個(gè)窗口上操作。如果這一步?jīng)]做好代碼編譯再干凈也無濟(jì)于事——寫入LCR會(huì)直接掉進(jìn)無效地址。原廠驅(qū)動(dòng)另一層隱含邏輯是“中斷共享的兼容”。9054的INTAn#掛在PCI INTA上很多老工控機(jī)上會(huì)和網(wǎng)卡、USB控制器共享中斷。原廠驅(qū)動(dòng)ISR最開始就是讀LINT_STATUS寄存器判斷是否屬于自己的中斷再?zèng)Q定要不要返回FALSE交給下一個(gè)ISR。這個(gè)機(jī)制在Win7下依然成立但DPC執(zhí)行要求更嚴(yán)等講到中斷改造的時(shí)候細(xì)說。3. Win7移植必須先過的編譯和簽名關(guān)口3.1 工具鏈WDK版本不是越高越好Win7時(shí)代的驅(qū)動(dòng)開發(fā)不像現(xiàn)在有一套完整的VSWDK全家桶當(dāng)年最常見的搭配是WDK 7600 Visual Studio 2008/2010。我試過用新版WDK去編譯老工程結(jié)果一堆DEPRECATED函數(shù)警告直接變成錯(cuò)誤wpp預(yù)處理宏的行為也變了平白無故給自己加阻力。所以第一原則就是老驅(qū)動(dòng)代碼盡量用和它年代匹配的WDK版本。編譯環(huán)境建議直接開WDK自帶的Build Environments窗口我用的是x64 Checked Build帶調(diào)試信息方便后面WinDbg分析。進(jìn)入源碼目錄執(zhí)行build -cZ這條命令的意思是清理之前的編譯輸出然后重新編譯生成文件的默認(rèn)路徑在SDK目錄下。編譯過程中如果你看到類似“C4996: deprecated”的警告大概率是某個(gè)內(nèi)核API在Win7里被標(biāo)成過時(shí)了。比如XP時(shí)代很多人喜歡用KeMaximizeProcessorCount但Win7引入了KeGetCurrentProcessorNumberEx這類新接口老代碼倒是能跑就是警告刷屏。我當(dāng)時(shí)的處理策略是不影響功能的警告全部保留只在絕對必要的地方做替換移植階段的工程紀(jì)律是“改動(dòng)越小越好”。還有一個(gè)細(xì)節(jié)sys文件的目標(biāo)名要確認(rèn)清楚。原廠工程打包出來的可能是P905x.sys或者PLX905x.sys而INF里對應(yīng)拷貝文件名必須一致大小寫雖然不敏感但別混用。前幾年見過一個(gè)同事把CopyFiles段寫成了拷給warehname.sys結(jié)果設(shè)備管理器里驅(qū)動(dòng)永遠(yuǎn)加載不進(jìn)去折騰了整一下午。3.2 INF文件x86和x64必須分開寫很多老INF只有XP/2000的節(jié)在Win7上裝不上或者裝了不生效問題大多出在INF的結(jié)構(gòu)上。Win7下載驅(qū)動(dòng)必須明確告訴系統(tǒng)你支持的是NTamd64還是NTx86如果Manufacturer節(jié)只寫了一個(gè)NT系統(tǒng)根本不認(rèn)。我整理的INF關(guān)鍵節(jié)結(jié)構(gòu)如下[Version] Signature $WINDOWS NT$ Class Unknown ClassGuid {4d36e97e-e325-11ce-bfc1-08002be10318} Provider %ProviderName% DriverVer 05/12/2013,6.1.7600.1 [Manufacturer] %ProviderName% DeviceList, NTamd64 [DeviceList.NTamd64] PCI\VEN_10B5DEV_9054SUBSYS_11223344REV_01 P905x_Driver, PCI\VEN_10B5DEV_9054 [P905x_Driver.NTamd64] CopyFiles P905x_CopyFiles [P905x_CopyFiles] p905xload.sys p905xapi.dll ...兩個(gè)容易忽視的點(diǎn)第一DriverVer的日期必須比Win7發(fā)布晚否則系統(tǒng)會(huì)認(rèn)為驅(qū)動(dòng)比系統(tǒng)自帶版本還老而拒絕優(yōu)先選擇第二x86版的節(jié)必須是DeviceList.NTx86、P905x_Driver.NTx86注意別圖省事只留一個(gè)NTamd64否則32位機(jī)器上永遠(yuǎn)報(bào)Code 10。如果硬件設(shè)備ID里的SUBSYS每個(gè)批次不一樣INF里最好把不帶SUBSYS的通配ID也寫上保持兼容面寬一些。3.3 驅(qū)動(dòng)簽名Win7 x64繞不過去的攔路虎在Win7 32位系統(tǒng)上驅(qū)動(dòng)沒簽名只是彈個(gè)警告點(diǎn)繼續(xù)還能用換成x64位系統(tǒng)沒有有效簽名的內(nèi)核驅(qū)動(dòng)會(huì)被直接拉黑這不是驅(qū)動(dòng)代碼寫得干不干凈的問題是加載策略在系統(tǒng)層面就禁止了。開發(fā)調(diào)試階段最省事的辦法是開啟系統(tǒng)的測試簽名模式bcdedit /set testsigning on然后在測試證書環(huán)境中用makecert做一個(gè)自簽名證書這里是示意流程不是生產(chǎn)方案makecert -r -pe -ss PrivateCertStore -n CNMyCompanyTestCert MyCompanyTest.cer inf2cat /driver:. /os:7_X64 /v signtool sign /v /s PrivateCertStore /n MyCompanyTestCert /t http://timestamp.digicert.com p905x.sys注意這個(gè)測試簽名方案只能在開發(fā)機(jī)上用機(jī)器重啟后testsigning如果被重置有些安全U盤和加固軟件會(huì)主動(dòng)關(guān)掉驅(qū)動(dòng)又會(huì)回到無法加載的狀態(tài)。正式交付時(shí)必須購買第三方內(nèi)核代碼簽名證書或者走WHQL認(rèn)證。有些項(xiàng)目工期緊直接拿去測試結(jié)果客戶現(xiàn)場一插卡就Code 56多半就是簽名問題。順手記一下區(qū)分方法設(shè)備管理器里設(shè)備圖標(biāo)正常但黃嘆號(hào)屬性說“此設(shè)備無法啟動(dòng)代碼10”和屬性說“無法驗(yàn)證此設(shè)備所需驅(qū)動(dòng)程序的數(shù)字簽名代碼52”后者的優(yōu)先級(jí)永遠(yuǎn)高于前者先處理簽名再談別的。我們在移植過程中就吃過這個(gè)虧排查了一下午驅(qū)動(dòng)代碼最后只是簽名沒裝進(jìn)證書庫。4. 從XP到Win7的驅(qū)動(dòng)代碼關(guān)鍵改造4.1 PnP StartDevice階段拿資源的方式變了XP下很多老代碼在IRP_MN_START_DEVICE處理函數(shù)里直接拿Parameters.StartDevice.AllocatedResources然后一通bf遍歷。Win7的PnP資源分配在部分機(jī)器上會(huì)返回兩個(gè)資源列表一個(gè)AllocatedResources一個(gè)AllocatedResourcesTranslated而且不同PCI橋枚舉出來的順序可能不一樣。如果代碼里寫死了PartialResourceList-PartialDescriptors[0]一定是Memory那在這類機(jī)器上就會(huì)拿錯(cuò)。我當(dāng)時(shí)改造的寫法是按字符串類型遍歷for (ULONG i 0; i partial-PartialResourceCount; i) { PCM_PARTIAL_RESOURCE_DESCRIPTOR desc partial-PartialDescriptors[i]; switch (desc-Type) { case CmResourceTypeMemory: // 記錄BAR映射物理地址 break; case CmResourceTypeInterrupt: // 記錄IRQL和向量 // 處理CM_RESOURCE_INTERRUPT_LEVEL_BASED break; case CmResourceTypePort: // IO端口資源9054本地總線可以是IO模式 break; } }Win7對描述符中的Flags要求也更嚴(yán)格。比如CM_RESOURCE_INTERRUPT_LATCHED和CM_RESOURCE_INTERRUPT_LEVEL_BASED兩種中斷觸發(fā)標(biāo)志處理不當(dāng)會(huì)導(dǎo)致中斷風(fēng)暴或者干脆不觸發(fā)。別覺得這步多余實(shí)際移植中我們遇到過系統(tǒng)從睡眠喚醒后資源列表變化舊的“取第0項(xiàng)”寫法直接訪問野指針?biāo){屏代碼0x000000D1就是這么來的。4.2 物理地址映射和DMA到了64位世界9054是32位地址空間的老芯片但Win7 x64系統(tǒng)分配給設(shè)備BAR的物理地址可能落在4GB以上這時(shí)候驅(qū)動(dòng)內(nèi)部如果還是用ULONG存物理地址直接截?cái)嘤成涑鰜淼牡刂繁劐e(cuò)。XP時(shí)代常見的映射寫法是PHYSICAL_ADDRESS physicalAddr; physicalAddr.QuadPart (ULONG)pRes-u.Memory.Start; PVOID pMap MmMapIoSpace(physicalAddr, length, MmNonCached);到了Win7 x64如果你的資源描述符里返回的物理地址本身就是64位上面強(qiáng)行截?cái)嗟?2位就會(huì)映射到完全錯(cuò)誤的物理頁面。正確做法是從CM_RESOURCE_LIST的desc-u.Memory.Start.QuadPart原始讀取不要自己強(qiáng)制轉(zhuǎn)換。排查手段很簡單接上內(nèi)核調(diào)試器在映射前后打印一下物理地址對比一下設(shè)備管理器屬性里的內(nèi)存范圍是否一致。DMA部分更要小心。PCI9054使用總線主控DMA數(shù)據(jù)傳送靠芯片內(nèi)部的DMA描述符而描述符里包裝的地址只能是32位。在Win7 x86上好辦物理地址天然4GB以內(nèi)到了x64上如果不是用X64系統(tǒng)的IOMMUDMA緩沖區(qū)一旦被分配器放到4GB之外9054根本夠不到。我當(dāng)時(shí)做了兩個(gè)保險(xiǎn)第一個(gè)驅(qū)動(dòng)里限制DMA緩沖區(qū)通過MmAllocateContiguousMemorySpecifyCache分配在4GB以下第二個(gè)建議在BIOS層面關(guān)閉對9054的VT-d重映射否則IOMMU在某些主板固件下會(huì)把DMA地址翻譯到高地址而老芯片的32位地址線又接不回來。這個(gè)選項(xiàng)在AMI的BIOS里一般叫“VT-d”或“Intel Virtualization Technology for Directed I/O”關(guān)掉后PCI傳統(tǒng)設(shè)備兼容性會(huì)明顯好一截。需要說明一下這屬于常見實(shí)踐中的擴(kuò)展配置如果你所在的行業(yè)不允許動(dòng)BIOS策略也可以保持IOMMU開啟但要額外寫一個(gè)DMA地址校驗(yàn)邏輯每次生成描述符前調(diào)用MmGetPhysicalAddress若返回值大于4GB就重新分配一塊低地址緩沖區(qū)再拷貝數(shù)據(jù)。代價(jià)是性能有約10%的損耗工業(yè)采集場景通常能夠接受。4.3 中斷例程和電源管理Win7更挑剔9054原廠驅(qū)動(dòng)里ISR處理流程本身不算復(fù)雜收到本地中斷后讀LINT_STATUS判定是哪類事件DMA完成、GPIO觸發(fā)、FIFO到達(dá)閾值然后清中斷把工作丟給DPC。Win7和XP的一個(gè)區(qū)別是DPC的內(nèi)容被執(zhí)行的環(huán)境更嚴(yán)格如果你的DPC里做了調(diào)試打印或者Sleep很容易觸發(fā)進(jìn)程掛起檢測。最好的習(xí)慣是把DPC里能做的都做了讀完?duì)顟B(tài)寄存器立刻用IoRequestDpc排進(jìn)隊(duì)列DPC例程里只做數(shù)據(jù)整理和IoCompleteRequest?？刹灰押臅r(shí)業(yè)務(wù)邏輯放在DPC里做。電源管理這塊是最容易被忽略的。9054板卡在Win7下默認(rèn)是支持S0/S3切換的。如果不處理IRP_MN_QUERY_CAPABILITIES系統(tǒng)會(huì)直接把設(shè)備當(dāng)成不支持電源管理來處理結(jié)果就是機(jī)器休眠喚醒后設(shè)備不工作或者反過來設(shè)備在喚醒后處于D3狀態(tài)但驅(qū)動(dòng)不知道所有讀寫超時(shí)。我移植時(shí)在PnP IRP里攔截了IRP_MN_QUERY_CAPABILITIEScase IRP_MN_QUERY_CAPABILITIES: { PDEVICE_CAPABILITIES caps (PDEVICE_CAPABILITIES)stack-Parameters.DeviceCapabilities; caps-DeviceState[PowerSystemWorking] PowerDeviceD0; caps-DeviceState[PowerSystemSleeping1] PowerDeviceD3; caps-DeviceState[PowerSystemSleeping2] PowerDeviceD3; caps-DeviceState[PowerSystemSleeping3] PowerDeviceD3; caps-DeviceState[PowerSystemHibernate] PowerDeviceD3; caps-DeviceState[PowerSystemShutdown] PowerDeviceD3; caps-WakeFromD3 TRUE; ... }然后在自己驅(qū)動(dòng)里處理IRP_MJ_POWER對D0-D3切換事件做寄存器保存和恢復(fù)動(dòng)作。經(jīng)驗(yàn)值9054的本地配置寄存器LCR切換前存下來到D0恢復(fù)時(shí)寫回去EEPROM不用重讀PCI配置寄存器由總線驅(qū)動(dòng)管理你不用管但本地寄存器必須自己兜底。最后再強(qiáng)調(diào)一個(gè)Win7新增的麻煩Storport和SCSI類老驅(qū)動(dòng)不會(huì)遇到但9054這種自定義DMA引擎如果沒注冊MmMapLockedPagesSpecifyCache的正確方式某些會(huì)直接觸發(fā)“DMA_ENGINE_TOO_OLD”這類專用錯(cuò)誤。別慌先查驅(qū)動(dòng)注冊DMA適配器的代碼確認(rèn)9054使用的是32位散開/聚集Scatter/Gather并且把MaximumPhysicalAddress設(shè)為4GB邊界以內(nèi)。5. 移植現(xiàn)場從Code 56到藍(lán)屏的排錯(cuò)實(shí)錄5.1 設(shè)備未知與Code 28INF節(jié)匹配問題移植過程中最容易碰到的第一個(gè)故障驅(qū)動(dòng)通過devcon或手動(dòng)更新安裝進(jìn)去但設(shè)備管理器里設(shè)備仍然躺在“其他設(shè)備”下狀態(tài)是“未安裝驅(qū)動(dòng)代碼28”。這個(gè)現(xiàn)象十有八九是INF的硬件ID匹配有問題。排查順序是這樣。先在設(shè)備管理器打開該設(shè)備的“詳細(xì)信息和屬性”把硬件ID完整貼出來一定有類似這樣的值PCI\VEN_10B5DEV_9054SUBSYS_00019054REV_01 PCI\VEN_10B5DEV_9054SUBSYS_00019054 PCI\VEN_10B5DEV_9054然后檢查INF文件看看[DeviceList.NTamd64]里到底寫了什么。一個(gè)常見的低級(jí)錯(cuò)誤是硬件ID某一段大小寫、或字段順序不一致Windows INF匹配對格式要求非常嚴(yán)格。還有一種是自己在INF里把VEN_10B5的Vendor ID拼錯(cuò)了轉(zhuǎn)成十六進(jìn)制時(shí)少一位匹配永遠(yuǎn)失敗。另外要注意如果是32位系統(tǒng)Windows默認(rèn)只去[DeviceList.NTx86]翻別把64位節(jié)當(dāng)萬能鑰匙寫。改INF改到頭禿時(shí)可以暴力驗(yàn)證設(shè)備管理器里右鍵“更新驅(qū)動(dòng)程序軟件”→“瀏覽計(jì)算機(jī)以查找驅(qū)動(dòng)軟件”→“從計(jì)算機(jī)驅(qū)動(dòng)列表選擇”人工指向sys所在目錄如果列表里能看到你驅(qū)動(dòng)的設(shè)備名說明INF和sys編譯鏈路是通的問題就只剩匹配精讀。5.2 Code 56簽名問題之外的玄學(xué)Code 56在Win7里屬于比較惡心的錯(cuò)誤全稱叫“設(shè)備已經(jīng)加載了一個(gè)驅(qū)動(dòng)但Windows無法啟動(dòng)它”。很多人第一反應(yīng)是簽名問題但Code 56和Code 52含義不同——Code 52明說數(shù)字簽名驗(yàn)證失敗Code 56的意思是驅(qū)動(dòng)sys已經(jīng)成功拷貝進(jìn)driverstore或者system32/drivers但在創(chuàng)建設(shè)備對象或響應(yīng)StartDevice時(shí)出錯(cuò)導(dǎo)致PnP回滾。解決這種問題我的第一反應(yīng)不是看代碼而是看日志。打開C:\Windows\inf\setupapi.dev.log這是安裝過程的完整流水賬。搜關(guān)鍵詞“! dvi”或“Error:”,可以看到Windows嘗試加載sys之后驅(qū)動(dòng)的返回狀態(tài)。舉例來說 [Device Install (UpdateDriverForPlugAndPlayDevices) - p905x.inf] Section start ... dvi: Searching for hardware ID PCI\VEN_10B5DEV_9054... dvi: Driver node selected: P905x Driver ! dvi: Driver package status 0x800F0219 (STATUS_INVALID_IMAGE_HASH)STATUS_INVALID_IMAGE_HASH基本上就把罪名坐實(shí)在簽名頭了去處理證書如果狀態(tài)碼是STATUS_DEVICE_PROTOCOL_ERROR或者STATUS_INSUFFICIENT_RESOURCES說明驅(qū)動(dòng)代碼里對資源映射的處理有問題回頭檢查第4.1節(jié)的資源遍歷到底有沒有拿全。還有一個(gè)隱蔽原因是“設(shè)備端禁止啟動(dòng)”。有些主板BIOS的PCI設(shè)備列表里把某個(gè)插槽設(shè)成了“禁止分配資源”設(shè)備管理器能枚舉到設(shè)備但起不來狀態(tài)碼同樣顯示Code 56。檢查方法是進(jìn)入BIOS調(diào)整PCI Latency Timer或者復(fù)位一下PCI資源分配表我當(dāng)時(shí)是直接把系統(tǒng)里另外一塊設(shè)備挪了個(gè)槽Code 56就消失了。這種情況和驅(qū)動(dòng)代碼一點(diǎn)關(guān)系都沒有。5.3 WinDbg加原廠監(jiān)控工具的聯(lián)合排障如果setupapi日志定位不出問題就得請出內(nèi)核調(diào)試器了。Win7測試機(jī)上把調(diào)試開關(guān)打開bcdedit /debug on bcdedit /dbgsettings serial debugport:1 baudrate:115200主機(jī)上用WinDbg串口連接加載符號(hào)之后先敲幾個(gè)常用命令定位現(xiàn)場kd !analyze -v kd lmvm p905x kd !pci 1 0 0 kd !devnode 0 1 kd !irp!pci 1 0 0是查看PCI總線0設(shè)備0功能0的配置空間對照硬件ID確認(rèn)板卡是否被系統(tǒng)正確發(fā)現(xiàn)如果這里的BAR寄存器數(shù)值不對大概率是EEPROM初始化或者系統(tǒng)資源重分配做壞事。!devnode 0 1能看到驅(qū)動(dòng)對象和FDO/PDO的狀態(tài)確認(rèn)PnP棧在哪里斷掉。實(shí)際上我們當(dāng)時(shí)一起用的還有原廠監(jiān)控工具。它能直接讀出PCI配置空間的BAR地址和本地寄存器的值。有一次設(shè)備長時(shí)間跑DMA后丟中斷我同時(shí)在WinDbg里看DPC隊(duì)列、用原廠監(jiān)控工具看LINT_STATUS寄存器一下子就確認(rèn)了中斷沒有被正確清掉代碼里少了寄存器讀后寫這個(gè)步驟而不是Win7的調(diào)度問題。這種本質(zhì)層面對齊比單純靠日志猜要快得多。這里順便給大家一個(gè)建議移植老驅(qū)動(dòng)監(jiān)控工具必須要能用。如果原廠工具在Win7上跑不起來很多老工具都是控制臺(tái)版只支持XP可以先用虛擬機(jī)裝一個(gè)XP來跑工具然后把實(shí)機(jī)Win7上的寄存器值截圖回來對比。這個(gè)臨時(shí)方案解決了很多現(xiàn)場不能亂裝工具的問題。6. 移植后的驗(yàn)證清單與量產(chǎn)部署經(jīng)驗(yàn)6.1 必須跑通的回歸項(xiàng)驅(qū)動(dòng)移植完只是開始離能交付還有一大截。下面這張表是我在項(xiàng)目里固定執(zhí)行的驗(yàn)證項(xiàng)全部通過才敢往生產(chǎn)環(huán)境發(fā)驗(yàn)證項(xiàng)具體方法通過標(biāo)準(zhǔn)基礎(chǔ)枚舉冷插/熱插PCI設(shè)備設(shè)備管理器無黃嘆號(hào)狀態(tài)正常資源映射原廠監(jiān)控工具讀BAR0-BAR3所有BAR地址非零且與資源窗一致寄存器讀寫對LCR輪詢并改寫控制字讀寫結(jié)果一致無總線錯(cuò)誤中斷驗(yàn)證觸發(fā)本地GPIO中斷5000次無丟失無SYSTEM_SERVICE_EXCEPTION藍(lán)屏DMA吞吐連續(xù)500MB雙向搬運(yùn)無ABORT無誤碼休眠喚醒進(jìn)入S3再喚醒設(shè)備恢復(fù)且能夠繼續(xù)DMA64位兼容Win7 x64安裝和全量測試驅(qū)動(dòng)簽名有效無截?cái)嗟刂穯栴}多卡并存同機(jī)安裝4塊板卡中斷共享正常所有板卡可獨(dú)立操作DMA吞吐這項(xiàng)我多說一句。9054老芯片在當(dāng)今內(nèi)存頻率下如果描述符塊設(shè)置太小DMA搬運(yùn)效率會(huì)很難看。我當(dāng)時(shí)的經(jīng)驗(yàn)是把DMA描述符環(huán)改成256字節(jié)對齊搬運(yùn)長度設(shè)成512字節(jié)起步連續(xù)搬運(yùn)時(shí)能看到穩(wěn)定占用PCI總線。如果單次搬運(yùn)在256字節(jié)以下浪費(fèi)在描述符管理上的時(shí)鐘反而占比過高。6.2 批量部署時(shí)的驅(qū)動(dòng)安裝技巧量產(chǎn)部署階段不建議再讓用戶手工“更新驅(qū)動(dòng)程序”。Win7下靜默裝驅(qū)動(dòng)我推薦用pnputil比老devcon更穩(wěn)微軟官方一直維護(hù)到Win11都還在用pnputil -i -a plx905x.inf關(guān)鍵點(diǎn)是“-i”表示向系統(tǒng)提交驅(qū)動(dòng)包安裝請求“-a”表示添加。加上之后設(shè)備上線時(shí)PnP會(huì)自動(dòng)搜索驅(qū)動(dòng)庫完成安裝。如果是先在插卡狀態(tài)下裝需要執(zhí)行兩次先添加驅(qū)動(dòng)包再刷新設(shè)備狀態(tài)。系統(tǒng)有時(shí)候反應(yīng)慢可以等待5秒再執(zhí)行一次掃描pnputil -i -a plx905x.inf ping -n 5 127.0.0.1 nul pnputil -d -i pci#ven_10b5dev_9054后一條命令是強(qiáng)制為指定設(shè)備實(shí)例安裝驅(qū)動(dòng)適合那些樹形結(jié)構(gòu)比較奇怪的機(jī)器。批量部署時(shí)還要注意證書預(yù)置。正式簽名證書如果還沒有推送到所有客戶端驅(qū)動(dòng)即使打包進(jìn)驅(qū)動(dòng)庫也會(huì)因?yàn)楹灻麊栴}被拒。一個(gè)很實(shí)用的辦法是用組策略把授信證書導(dǎo)入到“受信任的發(fā)布者”存儲(chǔ)再執(zhí)行驅(qū)動(dòng)部署。在測試環(huán)境先做一次干凈主機(jī)的全流程演練別在數(shù)百臺(tái)機(jī)器上直接跑測。6.3 從這個(gè)項(xiàng)目里沉淀下來的一些掌故移植結(jié)束了我想分享幾個(gè)這次經(jīng)歷帶給我自己的體會(huì)。第一條是老驅(qū)動(dòng)的移植最忌諱“大刀闊斧重寫”。剛拿到代碼的時(shí)候誰看誰難受到處都是全局變量和老式宏恨不得推倒重來。但9054板卡的價(jià)值在于它的時(shí)序已經(jīng)穩(wěn)定你要做的只是在Win7的新地基上給它換一套房子不是重新給它造一顆心臟。第二條設(shè)備擴(kuò)展DeviceExtension的設(shè)計(jì)直接影響后期的所有問題。我這次花了小半天把DeviceExtension重新梳理成結(jié)構(gòu)體嵌套把BAR地址、映射虛擬地址、資源列表長度、中斷狀態(tài)位全部歸攏后續(xù)調(diào)試時(shí)一眼就能從WinDbg里抓到這些變量。很多藍(lán)屏問題的根源就是指針存散著導(dǎo)致某一分支沒拿到完整上下文。最后一條“小技巧”是調(diào)試DMA問題時(shí)的土辦法在驅(qū)動(dòng)里臨時(shí)把每個(gè)DMA描述符的物理地址都回顯到一段內(nèi)核日志里用KDCOM或者WinDbg在主機(jī)端批量收集。9054的DMA失敗十有八九和描述符地址非法有關(guān)這一招可以快速確定是不是地址被放到4GB以上、或者描述符跨頁導(dǎo)致的對齊錯(cuò)誤。收集完這批日志再?zèng)Q定要不要加驅(qū)動(dòng)層內(nèi)存池比靠猜靠譜太多。每次看到這種幾年份的硬件在新系統(tǒng)上重新跑起來我心里其實(shí)挺踏實(shí)。技術(shù)上沒什么玄學(xué)就是一條一條把“系統(tǒng)換了之后誰不再按老規(guī)矩辦事”的差異找出來挨個(gè)填平。PCI9054的移植做完下一代的PCIe固件和KMDF驅(qū)動(dòng)架構(gòu)我們已經(jīng)在籌劃了路徑清晰不少。