例としてLynxpointコントローラーのGPIOを使用した_HID ACPIメソッドによるドライバーとデバイス間の通信

問題の声明

Linuxには、sysfsを介してGPIOを操作するための標準インターフェースがあります。 そのためのドキュメントはここにあります 。



要するに、「/ sys / class / gpio」フォルダーには「export」および「unexport」ファイルがあります。 番号Xをエクスポートファイルに書き込むことにより、ユーザー空間でインターフェイスを開いてGPIOXを制御できます

#    user space   GPIO12 $ echo 12 > /sys/class/gpio/export
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

インターフェースを開いた後、フォルダー/ sys / class / gpio / gpioX /が表示され、そこに「value」または「direction」などのファイルがあり、「direction」ファイルに「in」または「out」を書き込み、ファイルに1または0を書き込みます。 「値」は、コマンドラインからGPIO出力を直接制御できます。

 #  GPIO   $ echo "out" > /sys/class/gpio/gpio12/direction #  1   GPIO $ echo 1 > /sys/class/gpio/gpio12/value
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

echo X> / sys / class / gpio / exportコマンドでgpioXフォルダーを作成するには、GPIOコントローラードライバーをカーネルに登録する必要があります。これにより、GPIOラインへのインターフェイスが開きます。



Intel Haswell i7プロセッサをベースにしたカスタムボードのコアブートの移植に取り組んでいることがわかりました[知らない人のために、corebootはオープンソース（ https://www.coreboot.org/ ）のオープンソースBIOSプロジェクトです。 ]。 94個のGPIOラインがあるLynxpointLPサウスブリッジがプロセッサに組み込まれています。 そして、私はそれらをsysfsで開きたいと思いました...

問題解決（Linuxでのドライバーとデバイスの通信）

カーネルコードを少し検索した結果、このドライバーは既に作成されており、ファイル「drivers \ gpio \ gpio-lynxpoint.c」にあり、Kconfigを使用して有効になっていることがわかりました。

 config GPIO_LYNXPOINT tristate "Intel Lynxpoint GPIO support" depends on ACPI && X86 select GPIOLIB_IRQCHIP help driver for GPIO functionality on Intel Lynxpoint PCH chipset Requires ACPI device enumeration code to set up a platform device.
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

使用していたカーネルでGPIO_LYNXPOINTオプションが有効になりましたが、「/ sys / class / gpio /」フォルダー（あるべき）にGPIOコントローラー用の単一の「gpiochipN」フォルダーがなく、そのようなスクリプトでもエクスポートされませんでした行。

 $ for i in {0..255}; do echo $i > /sys/class/gpio/export; done
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

corebootコードまたはこのサウスブリッジのドキュメントを見ると、GPIOコントローラーが独立したPCIデバイスではないことがわかります。 それは別のPCIデバイスの一部です：LPC Interface Bridge。 このデバイスのPCI構成スペースレジスタを使用して、GPIOコントローラーを有効にし、I / OスペースでBASE_ADDRESSを割り当てる必要があります。 これにより、1KV I / Oスペースでウィンドウが開きます。 このウィンドウでバイトの書き込み/読み取りを行うことにより、GPIOラインを制御できます。



corebootコードで確認できるもの：



サウスブリッジ\インテル\ lynxpoint \ pch.h：

 #define DEFAULT_GPIOBASE 0x1400 #define DEFAULT_GPIOSIZE 0x400 ... #define GPIO_BASE 0x48 /* LPC GPIO Base Address Register */ #define GPIO_CNTL 0x4C /* LPC GPIO Control Register */ ... /* PCI Configuration Space (D31:F0): LPC */ #define PCH_LPC_DEV PCI_DEV(0, 0x1f, 0)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

サウスブリッジ\インテル\ lynxpoint \ early_pch.c：

 /* Setup GPIO Base Address */ pci_write_config32(PCH_LPC_DEV, GPIO_BASE, DEFAULT_GPIOBASE|1); /* Enable GPIO functionality. */ pci_write_config8(PCH_LPC_DEV, GPIO_CNTL, 0x10);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

LinuxのLPCデバイスレジスタを「lspci -xxx」で見ると、記録されたデータがこれらのレジスタにあることがわかります。 そのため、すべてが適切に構成されているようです。



ドライバーコードを調べ続けると、Linuxドライバーが.acpi_match_tableフィールドを介してデバイスに接続されていることに気付きました。 デバイスは列挙できないため（PCIまたはUSBバス上にはありません）、プラットフォームドライバーが必要であり、このドライバーとデバイスの接続はACPIテーブルを介して行われます。 x86の通常の場合、ARMの場合、DeviceTreeにデバイスを登録するか、カーネルの古いハードコードを使用します。



ドライバー\ gpio \ gpio-lynxpoint.c：

 static const struct acpi_device_id lynxpoint_gpio_acpi_match[] = { { "INT33C7", 0 }, { "INT3437", 0 }, { } }; MODULE_DEVICE_TABLE(acpi, lynxpoint_gpio_acpi_match); static struct platform_driver lp_gpio_driver = { .probe = lp_gpio_probe, .remove = lp_gpio_remove, .driver = { .name = "lp_gpio", .pm = &lp_gpio_pm_ops, .acpi_match_table = ACPI_PTR(lynxpoint_gpio_acpi_match), }, };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは次のように機能します。ACPIテーブルを解析するときにカーネルが_HID識別子「INT33C7」を持つデバイスを検出すると、構造「.driver-> acpi_match_table」のフィールドに一致する識別子を持つプラットフォームドライバを見つけようとします。



一致が見つかると、Linuxは.probeドライバー関数を実行します。



結局のところ、このデバイスのACPIコードはcorebootに表示されていたので、コメントアウトしました。 このデバイスではWindowsがドライバーを見つけることができず、デバイスマネージャーに「不明なデバイス」と表示されるという事実のためにコメントアウトされました。 詳細については、以下をご覧ください。



そのため、ファイルからの情報に興味があります

src \ southbridge \ intel \ lynxpoint \ acpi \ serialio.asl（コードは少し簡略化されています）：

 /*     * src\southbridge\intel\lynxpoint\pch.h * #define DEFAULT_GPIOBASE 0x1400 * #define DEFAULT_GPIOSIZE 0x400 */ Scope (\_SB) { Device (PCI0) { ... Device (GPIO) { // GPIO Controller Name (_HID, "INT33C7") Name (_CID, "INT33C7") Name (_UID, 1) Name (RBUF, ResourceTemplate() { DWordIo (ResourceProducer, MinFixed, // IsMinFixed MaxFixed, // IsMaxFixed PosDecode, // Decode EntireRange, // ISARanges 0x00000000, // AddressGranularity 0x00000000, // AddressMinimum 0x00000000, // AddressMaximum 0x00000000, // AddressTranslation 0x00000001, // RangeLength , // ResourceSourceIndex , // ResourceSource BAR0) Interrupt (ResourceConsumer, Level, ActiveHigh, Shared, , , ) {14} }) Method (_CRS, 0, NotSerialized) { CreateDwordField (^RBUF, ^BAR0._MIN, BMIN) CreateDwordField (^RBUF, ^BAR0._MAX, BMAX) CreateDwordField (^RBUF, ^BAR0._LEN, BLEN) Store (DEFAULT_GPIOSIZE, BLEN) Store (DEFAULT_GPIOBASE, BMIN) Store (Subtract (Add (DEFAULT_GPIOBASE, DEFAULT_GPIOSIZE), 1), BMAX) Return (RBUF) } Method (_STA, 0, NotSerialized) { Return (0xF) } } ... } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このコードを詳細に理解するには、ACPI仕様の ASL構文に精通する必要があります。



しかし、要するに、このコードは、2つのリソースを持つ識別子「INT33C7」を持つデバイスを作成します。

 I/O memory: 1400-17ff; IRQ: 14;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Linuxの.probe関数内で、ドライバーは上記のデバイスリソースを次のように受け取ります。

 io_rc = platform_get_resource(pdev, IORESOURCE_IO, 0); irq_rc = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このデータに基づいて、ドライバーコードはgpio_chip構造体に入力し、システムにgpioコントローラーを登録します。これにより、sysfsインターフェイスからアクセスできるようになります。



デバイスのASLコードを返し、BIOSイメージを再コンパイルすると、システムはsysfsを介してGPIOにアクセスできました。



まず、フォルダー「gpiochip162」は/ sys / class / gpioにあります。 このフォルダには、ファイル「base」と「ngpio」が含まれています。 基本ファイルは、このコントローラーの最初のGPIOの番号を担当し、その番号はngpioです。

 $ cat /sys/class/gpio/gpiochip162/base 162 $ cat /sys/class/gpio/gpiochip162/ngpio 94
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

したがって、すべてが正常にエクスポートされました。 スクリプトを実行します。

 $ for i in {162..255}; do echo $i > /sys/class/gpio/export; done
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

その後、gpioNサブフォルダーが/ sys / class / gpio /フォルダーに表示され、その中に回線の状態を制御するファイルがあります。



いくつかのコメント：

• / sys / class / gpio162 /フォルダーはGPIO0を管理し、/ sys / class / gpio163 /フォルダーはGPIO1を管理します このシフトは、制御構造「struct gpio_chip」の初期化中にドライバーが「gc-> base = -1;」を割り当てたために発生しました。 つまり、数字を自分で選択するためにカーネルを離れました。 これは一般に重要ではありませんが、覚えておく価値があります。
• アクセスは、GPIOとして構成されたGPIO回線にのみ許可され、ネイティブのサウスブリッジ機能としては許可されません。 そのような行の場合、ドライバーはdmesgに情報を表示します：「gpio％d reserved for ACPI」。 corebootの場合、GPIOはマザーボードのあるフォルダーの「gpio.h」ファイルで構成されます。
• デバイスとドライバーは、_CID（互換性ID）メソッドを使用してマップすることもできます。カーネルのトピックに関するドキュメントは、ドキュメント「ACPIベースのデバイス列挙」に記載されています。

INT33C7デバイスには、ACPIテーブル（IBASEとDFIから）の同じチップセット上に2つの専用マザーボードがないことに注意してください。 確かに、GPIO行が出力されない可能性が最も高い（その時点でドキュメントを詳細に見ていない）。

識別子「INT33C7」

sysfs機能を上げた後、「INT33C7」識別番号はどこから来たのかという質問がありました。



_HIDメソッドのドキュメントを見ると、 http： //www.uefi.org/PNP_ACPI_Registryを見る価値があることが明らかになりました。





このリンクには3つのポイントがあります。

• すべてのタイプの3文字の識別子（PNP ID）がここに示されています
• ここでは、Microsoftが予約した「PNP」で始まるPNP IDを示します。
  
  
• すべての種類の4文字の識別子（ACPI ID）がここに示されています

理由は明確ではありませんが、PNP IDリストから、「INT」識別子がINTERPHASE CORPORATIONで予約されていることがわかります。

 INTERPHASE CORPORATION INT 11/29/1996
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

どうやら、完全なデバイス識別子の単一リスト（文字部分+デジタル）は公開されていません。 しかし、Googleの助けを借りて、たとえばここまたはここでデバイスのリストと_HIDを見つけることができました 。



彼らは示します：

 INT33C7=Intel Serial I/O GPIO Host Controller
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、このリストの残りの行から判断すると、すべてのINTxxxxデバイスはIntelデバイスです（今では非常に明白に聞こえますが、INTERPHASE CORPORATIONとの接続はまだ明確ではありません。また、番号がこのような大きな数字で始まる理由はあまり明確ではありませんが、 Intelの裁量）。

Windowsの通信ドライバーとデバイス

好奇心を満たしたので、ボードにWindowsをロードすることにしました。 予想どおり、システムはデバイスのドライバーを見つけることができませんでした。 IBASEおよびDFIボードのドライバーからの助けはありませんでしたが、これらのボードのBIOSではこのデバイスが示されていないため、理解できます。



Microsoft Webサイトでドライバーを見つけることができました



ただし、このドライバーはWindows 8.1以降でのみ表示されます。 私はまだWindows 7で作業しています。



それでも、未知のデバイスのドライバーを検索するときに、ドライバーの1つをダウンロードして、そのフォルダーを指定しようとしました。



ただし、ディスパッチャはドライバをデバイスにマップできませんでした。 infファイルにはINT33C7デバイスに関する情報が明確に含まれていましたが。

 [Manufacturer] %INTEL%=Intel,NTamd64.6.3 [Intel.NTamd64.6.3] %iaLPSS_GPIO.DeviceDesc_LPT%=iaLPSS_GPIO_Device, ACPI\INT33C7 %iaLPSS_GPIO.DeviceDesc_WPT%=iaLPSS_GPIO_Device, ACPI\INT3437
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

INFファイルを解析する過程で、[Manufacturer]セクションが、それが私のシステム向けではないことを明確に示していることがわかりました。



Intel.NTamd64.6.3の意味は、説明から理解できます。

 nt[Architecture][.[OSMajorVersion][.[OSMinorVersion] OSMajorVersion=6 => Windows 7/Windows 8.1/Windows Server 2012 R2/... OSMinorVersion=3 => Windows 8.1/Windows Server 2012 R2
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Intel.NTamd64.6.3をIntel.NTamd64.6.1に置き換えてWindows 7ドライバーをプッシュしようとしましたが、それをやや失敗させました。死のブルースクリーンと起動不可能なOSが表示されたため、回復する必要がありました。



Win7のドライバーは、インターネット上の理解できないサイトでのみ検出され、その後、デバイスマネージャーのデバイスが感嘆符付きで表示されます。



彼の無力さを実感し、Windows 10で機能をテストすることにしました。嬉しい驚きがありました。 Intelチップセットデバイスソフトウェア（INF更新ユーティリティ）は、コントローラー用のドライバーを問題なくインストールしました。







ご覧のとおり、このデバイスには当社が示したリソースがあります。







理論的には、GPIOコントローラーを使用してドライバーをインストールした後、IOCTL関数（ このドキュメントなど）を使用して作業することが可能になる可能性が最も高くなります。



しかし、WindowsからのGPIOプログラミングタスクは耐えられなかったため、チップセットの同様のドキュメントの検索は延期されました。

---

結論：

この記事では、_HID ACPIメソッドを使用して、ドライバーとデバイス間の接続を調べました。 このような通信は、列挙できないデバイスのx86システムで必要になる場合があります。

• Linuxの場合、ドライバーとの通信は.acpi_match_tableを介して行われます
• Windowsの場合、ドライバーとの通信はINFファイルを介して行われます