ACPIを使用したロードの初期段階での機器の構成（FreeBSDの例）

数年前、CardBusとFireWire（IEEE 1394）がまだ比較的「使用」されていたとき、多くのラップトップメーカーは製品にTexas Instruments PCIXX21およびPCIXX11ファミリーのコントローラーを使用していました。リムーバブルメモリカードの標準。



このようなチップ（つまり、PCI7411）は、私のNEC Versa S950にもあります。 このあまり知られていないラップトップは、FreeBSD（一般に機器と特にスリープモード）のサポートが優れているため、ThinkPadシリーズをほぼ独占的に使用しました。購入する前にNovosibirsk Technosityで特別にテストしました。 長い間、USBのホイッスルを使用する習慣から、組み込みのカードリーダーは使用しませんでした。 しかし最近、FreeBSDがまだサポートしていないことを発見しました。 5、6年前にこれらのコントローラー用の通常のドライバーがないことで説明できる場合（自分で何かをダウンロードして組み立てる必要がありました）、FreeBSDのsdhci(4)



ドライバーでサポートされている「 sdhci(4)



」ことを確信しましたsdhci(4)



、これはマニュアルページに明記されています（後でソースを読むことで確認されます）。



私はこのトピックについてゆっくりとグーグルを始め、写真は不幸になり始めました。 私のような「幸運な人」がたくさんいることがわかりました。 多くの人がdmesg



とpciconf -lv



メーリングとフォーラムに投稿し、トラッカーのバグ（たとえば、OpenBSD PR i386 / 5843）を開始しましたが、誰も解決策を提供しませんでした。 さらに、 sdhci(4)



ドライバーの作者であるAlexander Motin sdhci(4)



、実際に質問に終止符をsdhci(4)



、2010年のフォーラムで、チップのTIドキュメントを提供しなかったと書いています。つまり、メーカーがチップを誤って構成し、 BIOSは提供されていません。何もすることは困難です。 次に、Theo de Raadtはi386 / 5843を次の言葉で閉じました。 このベンダーは、とりわけ、sdhcコントローラーをロックアウトし、文書化されていない小さなビットの後ろに隠しています。 この情報を見つけるのに苦労しましたが、失敗しました。 この情報を他のオペレーティングシステムやベンダーのドキュメントで見つけることができれば、わくわくします。」



必死になって、Ubuntu LiveCDから起動しました。 そして、Linuxカードリーダーが機能することに非常に驚きました。 だから...

ひどくグーグル

2006年にAlex DubovがTI FlashMediaリーダー用のLinuxドライバーを作成したことが判明しました。 私はソースをダウンロードし、それらを研究し始めました。その後、 sdhci(4)



完成さsdhci(4)



か、ドライバー全体をスポーツすることさえ望みました。 まず、サポートされているPCIベンダー/デバイスIDのリストを見て、「当社の」ドライバーと比較しました。 それは小さいことが判明しました：

 $ cat linux/pci_ids.h #define PCI_VENDOR_ID_TI 0x104c #define PCI_DEVICE_ID_TI_XX21_XX11_FM 0x8033 #define PCI_DEVICE_ID_TI_XX12_FM 0x803b #define PCI_DEVICE_ID_TI_XX20_FM 0xac8f
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

番号0x8033は、ラップトップのpciconf -lv



の出力から既によく知られています（チップ= 0x8033 104c）：

 none3@pci0:6:7:3: class=0x018000 card=0x83191033 chip=0x8033104c rev=0x00 hdr=0x00 vendor = 'Texas Instruments (TI)' device = 'PCIxx11/21 Integrated FlashMedia Controller' class = mass storage
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは、FreeBSDでは動作しませんが、Linuxでは動作するカードリーダーです。 そして、これはsdhci.c



（FreeBSD）のコードです：

 static const struct sdhci_device { uint32_t model; uint16_t subvendor; char *desc; u_int quirks; } sdhci_devices[] = { { 0x08221180, 0xffff, "RICOH R5C822 SD", SDHCI_QUIRK_FORCE_DMA }, { 0xe8221180, 0xffff, "RICOH SD", SDHCI_QUIRK_FORCE_DMA }, { 0xe8231180, 0xffff, "RICOH R5CE823 SD", SDHCI_QUIRK_LOWER_FREQUENCY }, { 0x8034104c, 0xffff, "TI XX21/XX11 SD", SDHCI_QUIRK_FORCE_DMA },
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

デバイス識別子TI XX21 / XX11 SD（0x803 4 104c）は1桁の精度で私のもの（0x803 3 104c）に似ていることに気付くかもしれません。 さらに、CardBus（0x8031104c）とFireWire（0x8032104c）コントローラーのIDは似ているだけでなく、すべてのデバイスのPCIセレクターは機能番号のみが異なり、すべて同じデバイスを持っていることに気付きました。

 none1@pci0:6:7:0: class=0x060700 card=0x83191033 chip=0x8031104c rev=0x00 hdr=0x02 vendor = 'Texas Instruments (TI)' device = 'PCIxx21/x515 Cardbus Controller' class = bridge subclass = PCI-CardBus none2@pci0:6:7:2: class=0x0c0010 card=0x83191033 chip=0x8032104c rev=0x00 hdr=0x00 vendor = 'Texas Instruments (TI)' device = 'OHCI Compliant IEEE-1394 FireWire Controller' class = serial bus subclass = FireWire
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

チップには実際に両方のコントローラー（SDHCIとFlashMedia）が実装されているというSasha Motinの言葉を思い出して、私はより意図的に検索を開始し、すぐに別の投稿に出くわし、その後、freebsd-mobile @ newsletterに同様のメッセージ （少しだけ別の）HP NC6220の問題。 実用的なソリューションはどこにも提供されていませんでしたが、「ドライバーの最新バージョンを試してみる」や「申し訳ありませんが、飛行中のようです」といった愚かなヒントに要約されたほとんどの議論とは異なり、少なくとも、チップ構成は何らかの形でPCI機能ダンプに表示され（変更可能）、最も重要なことは、 PCIXXX21 / PCIXXX11 Implementation Guideのドキュメントがまだ利用可能であることです。 そして、それは私にとって本当に興味深いものになりました。



これから先、最も驚くべきことは、「ムーディー」チップ上で実質的にデータシートを掘り下げた人々が、問題の解決から一歩離れることを止めたということです。 ドキュメントを適切に使用する方法に関するレシピを誰も見つけませんでした（この投稿を書くように促されました）。 しかし、まず最初に。



PCIXXX21 / PCIXXX11実装ガイド-これらのコントローラーに基づくハードウェア設計者向けの117ページのドキュメント。 詳細に分析することは意味がありません。 私がそれから学んだ最も重要なこと：コントローラーは実際に5つの機能を実装しています：CardBus、1394、FlashMedia、SD Host、SmartCard。 通常、初期設定はEEPROMから取得されます。 メインコンフィギュレーションレジスタ-General Control Register（セクション12.4.28、p。65）-ROMの1Eh-1Fhアドレスにあり（チップファンクションがマスクされているので、バイトゼロにのみ関心があります）、ゼロファンクションのPCIオフセット86hに対応しますデバイス。 今-

ビジネス向け

最初に、 pciconf(8)



ユーティリティがチップの「ヘッド」（ゼロ）機能のPCI構成スペース、つまりFreeBSDの用語でpci0:6:7:0



セレクターについて教えてくれます。 簡潔にするために、256バイトすべてをダンプするわけではありませんが、オフセット86hで、関心のあるものだけに制限します。

 # pciconf -rb pci0:6:7:0 0x86 d3
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

面白い。 pdfの65ページのプレートを見ると、下位ニブル（ニブル）のトリプルは、トップレベルの調停、スマートカードソケットの電力制御、およびOHCI 1394を担当するビットの典型的な値に等しいことがわかります。 しかし、最上位のニブルは、残りのコントローラーのロジックをマスク（オン/オフ）するだけです（スペースを節約するために、テーブル全体を再度表示することはありません）。











0xDは1101、つまり DISABLE_SC、 DISABLE_SD 、およびDISABLE_SKTBビットが設定され、DISABLE_FMビットがクリアされます。 したがって、SDホストコントローラーを「復活」させるには、論理的に、DISABLE_SD（有効）をリセットし、反対にDISABLE_FMを設定（無効）する必要があります。 マスク1011は値0xBに対応します。 実際、バイト0xD3を0xB3に変更する必要があります。 ただし、問題は、チップを初期化する前、または組み込むコントローラーを決定する前に、事前にこれを十分に行う必要があることです。 システムの起動後、構成を変更しても意味がありません。すべてのデバイスはすでに「動作中」です。 そして、私たちの助けになります

ACPI

ACPIとは何か、なぜ必要なのかについては説明しません。これはトピックの範囲外であり、さらにこのトピックに関するHabréの良い投稿がありました。 この場合、私たちにとって重要な質問は、チップが初期化される前にDSDTにパッチを適用して、目的のコントローラー（SDホスト）をオンにし、ドライバー（FlashMedia）を持たない不要なコントローラーをオフにすることです。



ACPIのインタープリター（「仮想マシン」）のフレームワーク内で情報をデバッグおよび出力するための手段を見てみましょう。 ACPI仕様 （19.5.25項、p。733）では、オペレーティングシステムがユーザーに「伝える」必要がある特別なDebug



オブジェクトについて言及しています。 FreeBSDでは、1に設定する必要があるdebug.acpi.enable_debug_objects



システム変数がこれを担当します。

 # sysctl debug.acpi.enable_debug_objects=1 debug.acpi.enable_debug_objects: 0 -> 1
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これでDebug



に任意の行を書き込むことができ、FreeBSDカーネルはそれらをコンソールに出力します。 オンデマンドで関心のある情報をACPIに発行させる方法を理解することは依然として残っています。 まず、ラップトップのDSDTをダンプおよび分解し、調査します。

 # acpidump -dt > s950.asl
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

私は、「鉄」の動作に実質的に影響を与えずに、何らかの外部効果（またはバッテリーのポーリングなどの内部的な、しかし定期的な）によって呼び出されるメソッドを見つけることにしました。 DSDTコードを調べると、奇妙な作品に出会いました。

 Method (_Q0C, 0, NotSerialized) { If (\_SB.PCI0.PEGA) { \_SB.PCI0.PEGP.VGA.SWIH () } Else { Store (0x01, TLST) HKDS (0x0A) } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

メソッド\_SB.PCI0.PEGP.VGA.SWIH



呼び出される場所は他にありません。その名前は、これが何らかのディスプレイスイッチであることを示唆しています。 多くのラップトップのキーボードでは、ファンクションキーの1つがFn-modifierと組み合わされて、ビデオ出力を内部ディスプレイから外部ディスプレイに切り替えます。 私の「バージョン」ではF3です。 メソッドコードを次のように変更してみましょう。

  Method (_Q0C, 0, NotSerialized) { + Store ("Fn-F3 pressed", Debug) If (\_SB.PCI0.PEGA) {
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ASLを再構築します。

 # iasl s950-patched.asl Intel ACPI Component Architecture ASL Optimizing Compiler version 20101013-32 Copyright (c) 2000 - 2010 Intel Corporation ASL Input: s950-patched.asl - 7749 lines, 280987 bytes, 2840 keywords AML Output: /tmp/acpidump.aml - 24863 bytes, 640 named objects, 2200 executable opcodes Compilation complete. 0 Errors, 0 Warnings, 0 Remarks, 958 Optimizations # cp /tmp/acpidump.aml /root/s950-patched.aml
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

FreeBSDがブート時にテーブルを使用するために、/boot /boot/loader.conf



次の行を追加/boot/loader.conf



ます：

 acpi_dsdt_load="YES" acpi_dsdt_name="/root/s950-patched.aml"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

すべてが正しく行われ、計算が正当化されると、Fn-F3をクリックすると、コンソールにFn-F3キーが押されたというカーネルメッセージ（高輝度）が表示されます。 ACPIを操作できるようになったので、試してみましょう

レジスタ86hをノックする

さまざまなデバイス（RAM、入力/出力ポート、拡張カード、CMOS、IPMIなど）の物理アドレス空間は、いわゆる形式でACPI名前空間にマッピングされます。 通常、1つ以上の名前付き「仮想レジスタ」またはフィールド単位（仕様のパラグラフ19.5.96、p。782）で構成されるビットフィールド（Field）が内部に割り当てられる操作領域（OperationRegion）。 コントローラーのOperationRegionは、たとえば次のようになります。

 OperationRegion (PCIC, PCI_Config, 0x00, 256) Field (PCIC, AnyAcc, NoLock, Preserve) { Offset (0x86), // General Control Register   86h TLA, 2, // Top level arbitration SCSP, 1, // SmartCard socket power OHCI, 1, // Disable OHCI 1394 controller function SKTB, 1, // Disable CardBus socket B FM, 1, // Disable FlashMedia function SD, 1, // Disable SD host controller function SC, 1, // Disable SmartCard function }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

あるいは、256バイトすべてがOperationRegion



で宣言されているわけではない場合でも、さらに簡単ですが、関心があるだけで、コンフィギュレーションレジスタの個々のビットを選択しません。

 OperationRegion (PCIC, PCI_Config, 0x86, 0x01) Field (PCIC, AnyAcc, NoLock, Preserve) { GCR0, 8, // General Control Register (Byte 0) }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そのような定義自体は役に立たないことに気付くのは簡単です。それはどのデバイスにも結び付けられておらず、本質的に既知のオフセットでの1バイトの構造にすぎません。 DSDTのデバイスは、キーワードDevice



（パラグラフ19.5.30、p。735）で指定されます。 すべてのデバイスの全体は一種のツリーです。 そのため、すべてのPCIデバイスはほとんどの場合、ルートPCIバスに対応するデバイス空間\_SB.PCI0



内に配置されます（通常、バスは1つだけですが、理論的には1つのPCIドメインに最大256まであります）。



バス上のデバイスを識別するには、（device << 16）|という形式でアドレスを設定する必要があります。 機能。 この場合（ pciconf -lv



の出力を覚えていますか？）Function = 0、device = 7、bus =6。つまり、デバイスは明らかに次のようになります。

 Device (XX11) { Name (_ADR, 0x00070000) // pci0:6:7:0 }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

わかりましたが、6番目のタイヤはどこから来たのですか？ そして、彼女はDSDTのどこにいますか？ カーネルdmesg



（ dmesg



）を見てみましょう。

 $ dmesg | grep pci6 pci6: <ACPI PCI bus> on pcib4 pci6: <bridge, PCI-CardBus> at device 7.0 (no driver attached) pci6: <serial bus, FireWire> at device 7.2 (no driver attached) pci6: <mass storage> at device 7.3 (no driver attached) pci6: <network> at device 8.0 (no driver attached) $ dmesg | grep pcib4 pcib4: <ACPI PCI-PCI bridge> at device 30.0 on pci0 pci6: <ACPI PCI bus> on pcib4
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

pci6



は、PCI-PCIブリッジ上の追加の「仮想」バスであることがpci6



ました。 FreeBSDがデバイスを配布したため、6番（ブリッジの4番）を得ました。 もちろん、DSDT内には6つのバスと4つのブリッジはありません。 ブリッジ- Device (PCIB)



-予想どおり、まさに1つです。 完全な説明は次のようになります（レジスタを個別のビットに分解することなく、簡単なバージョンを示します）。

 Scope (\_SB.PCI0.PCIB) { Device (XX11) { Name (_ADR, 0x00070000) // pci0:6:7:0 OperationRegion (PCIC, PCI_Config, 0x86, 0x01) Field (PCIC, AnyAcc, NoLock, Preserve) { GCR0, 8, } } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これで、 _Q0C



メソッドのデバッグコードをより意味のあるものに置き換えることができます。

  Method (_Q0C, 0, NotSerialized) { + Store (Concatenate("GCR0 = 0x", \_SB.PCI0.PCIB.XX11.GCR0), Debug) If (\_SB.PCI0.PEGA) {
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ASLを再構築し、再起動して、Fn-F3を押します。 すべてを正しければ、以前pciconf(8)



読んだのと同じ値が表示されるはずです。











（レジスタ値を直接ビデオメモリに書き込むための関数の実装は、簡単な演習として読者に任されています。）



最も重要な質問に答える必要があります。レジスタの値を変更し、必要に応じてチップを強制的に設定することは可能でしょうか？



ACPI標準は、デバイスを初期化するための特別な方法、 _INI



を定義しています（6.5.1項、349ページ）。 デバイスに次のコードを追加します。

 Method (_INI) { Store (0xB3, GCR0) /*     : Store (0x01, FM) Store (0x00, SD) */ }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ASLをコンパイルし、結果のAMLファイルを/root/s950-patched.aml



にコピーして、再起動します。 見て

結果

まず、0x803 3 104c（FlashMedia）コントローラーがpciconf -lv



から消えたが、0x803 4 104c（SDホスト）が表示されたことに注意してください。 必要なカーネルモジュールをロードし、カードを挿入してマウントを試みます。

 # kldload sdhci mmc mmcsd # ls /dev/mmcsd0* /dev/mmcsd0 /dev/mmcsd0s1 # mount -t msdosfs /dev/mmcsd0s1 /mnt/tmp # ls /mnt/tmp/DCIM/100CANON IMG_0403.JPG IMG_0424.JPG IMG_0450.JPG IMG_0494.JPG IMG_0515.JPG IMG_0406.JPG IMG_0425.JPG IMG_0451.JPG IMG_0498.JPG IMG_0517.JPG IMG_0407.JPG IMG_0427.JPG IMG_0452.JPG IMG_0499.JPG IMG_0518.JPG IMG_0409.JPG IMG_0429.JPG IMG_0453.JPG IMG_0500.JPG IMG_0520.JPG IMG_0410.JPG IMG_0430.JPG IMG_0467.JPG IMG_0501.JPG IMG_0522.JPG IMG_0412.JPG IMG_0439.JPG IMG_0473.JPG IMG_0506.JPG IMG_0525.JPG IMG_0413.JPG IMG_0440.JPG IMG_0474.JPG IMG_0507.JPG IMG_0526.JPG IMG_0414.JPG IMG_0445.JPG IMG_0475.JPG IMG_0508.JPG IMG_0534.JPG IMG_0415.JPG IMG_0447.JPG IMG_0478.JPG IMG_0510.JPG IMG_0535.JPG IMG_0421.JPG IMG_0448.JPG IMG_0492.JPG IMG_0512.JPG IMG_0537.JPG IMG_0423.JPG IMG_0449.JPG IMG_0493.JPG IMG_0514.JPG IMG_0538.JPG # tar cf /dev/null /mnt/tmp/DCIM/100CANON ; echo $? tar: Removing leading '/' from member names 0
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

すべてがうまく機能しているようです。 DSDTからデバッグコードを削除し、カードリーダーを使用して生活を楽しむことができます。