Intel GalileoでのUEFIドライバーの開発とデバッグ、パート3：ハードウェアデバッグを開始

こんにちは、Habrの親愛なる読者。
短い休憩の後、Intel GalileoオープンハードウェアプラットフォームでのUEFIコンポーネントの開発とデバッグに関するメモ（ first 、 second ）を公開し続けています。 第3部では、FT2232HベースのJTAGデバッガーをGalileoに接続し、そのデバッグ環境をセットアップすることについて説明します。

エントリーと免責事項

すでに確立された伝統によれば、以下のすべての情報を自分の危険とリスクで使用することに言及する必要があります。著者は、取締役会のパフォーマンス、時間、気分、および/または人類への信頼を失う可能性について責任を負いません。 記載されているものはすべてオープンソースから引用されており、そのリストはこの記事の最後に記載されています。この出版物は、私の側のNDAの違反とは見なされません。

出発点

現時点では、Yocto LinuxのファームウェアとイメージをコンパイルしたIntel Galileoボードが既にあり、いつでも再実行できると想定しています。 記事のこの部分では、ガリレオのソフトウェアのアセンブリについては触れません。必要であれば、 最後の部分を読んでください。
また、OpenOCDと互換性のあるデバッガーがあることを意味します。何よりも-FTDI FTxx32Hシリーズチップに基づいています。 これらは、IntelエンジニアがGalileoのデバッグツールを作成およびテストするために使用するものです。 他のデバッガーが動作しないことを保証できません-私はチェックしませんでした。 この記事では、 FT2232Hブレイクアウトボードをデバッガとして使用します 。これは 、美しいケースとGalileoでのデバッグには不要なロジックレベルシフトチップがない場合のみ、同じチップ上の「アダルト」デバッガとは異なります。

鉄部分

鉄の部分では、すべてが非常に簡単です-必要なのは、GalileoのJTAGコネクタの接点を必要なFT2232H端子に正しく接続するだけです。
FTxx32Hシリーズチップの出力にはxyBUSzのマークが付いています。xの代わりにチャネルの指定（A、B、C、またはD）、yの代わりに各チャネルの最初の（D）または2番目（C）の端子セットの指定、zの代わりに出力番号（最初の結論は0〜7、2番目の結論は0〜9）。
JTAGを使用するには、次のように接続する必要があります。

  xDBUS0 <-> TCK
 xDBUS1 <-> TDI
 xDBUS2 <-> TDO
 xDBUS3 <-> TMS 

TRSTは同じチャネルの任意のフリー出力に接続できます。私の場合はxCBUS0であり、他のものを使用できますが、OpenOCD構成で対応する変更を行う必要があります。

ソフトウェア部

Intel System Studioを入手します

しかし、特にsudo apt-get install openocdを実行する方法がなく、10秒後にデバッガーの構成の書き込みを開始する Windowsユーザーの場合、すべてが少し複雑になります。 Intelの人々はこれを知っているため、OpenOCDとGDBをIntel System Studio 2015 Betaの配布キットに含めました。 登録後、こちらからダウンロードできます 。 また、GDBのGUIとして機能するIntel System Debuggerもあり、コンソールから直接操作するのに十分なTaoをまだ理解していない人向けに設計されています。 あなたの謙虚な召使はすでにこの道に乗り出しましたが、それは難しいことであり、GUIを使用する誘惑は素晴らしいものです。Intelはそれほど前にUEFIデバッグのサポートを追加しなかったからです。 その結果、私は屈服し、あなたに屈服することを提案します。
ISSを登録、ダウンロード、インストールした後、いくつかの追加手順を実行する必要があります：デバッガーの構成を記述する（デフォルトでは、 TinCanTools FLYSWATTER2とOlimex ARM-USB-OCD-Hのみの構成があります）、Cコードをデバッグできるようにデバッグシンボルを接続します、アセンブラーではありません。 Windowsでは、OpenOCDが検出できるように、標準のFTDIドライバーではなく、選択したデバッガーチャネル用のlibusbKドライバーもインストールする必要があります。 始めましょう。

OpenOCDの構成を作成します

OpenOCDのセットアップは通常、2つの部分で構成されます：デバッガーの構成の書き込みとデバッグ対象のボード。 優れたIntel開発者は2番目から私たちを救ってくれました。 System Studioをインストールしたディレクトリに移動し、そこからdebugger \ openocd \ scripts \ interface \ ftdiに移動し 、ファイルolimex-arm-usb-ocd-h.cfgをコピーして、コピーdebugger.cfgに名前を付けます 。 作成したファイルをお気に入りのエディターで開き 、 ftdi_vid_pid行のftdi_device_desc 、 ftdi_layout_signal nSRST 、 ftdi_layout_signal LEDの行を削除し、デバッガーのVIDとPIDを値に変更します。 チャネルB、C、またはDを使用する場合は、それぞれ行ftdi_channel 1 、 ftdi_channel 2またはftdi_channel 3を追加します。 デバッガの変更と構成を保存する準備ができました。
ftdi_layout_init行のマジックナンバーの意味を知りたい場合は 、追加の信号を設定するか、xCBUS0から別の出力にTRSTを転送します 。 ドキュメントへようこそ 。

libusbKドライバーをインストールする

Linuxユーザーはこの手順を安全にスキップできます。 正しいドライバーが既にインストールされています。 Windowsユーザーは、標準のドライバーの代わりに前述のドライバーをインストールする必要があります。 これを行うにはいくつかの方法がありますが、最も簡単な方法は、 Zadigユーティリティを使用することです。 最新バージョンをダウンロードして実行し、[ オプション ]メニューの[ すべてのデバイスを一覧表示 ]チェックボックスをオンにし、リストからデバイスを選択し、ドライバーとしてlibusbKを選択し、[ドライバーの置換 ]ボタンをクリックします。
すべてが正しく行われると、プログラムウィンドウは次のようになります。

OpenOCDの動作確認

次に、デバッガーが正しく接続され、OpenOCDがそれを使用してJTAG経由でGalileoにアクセスできることを確認する必要があります。 これを行うには、openocdを実行して、デバッガー（最初の手順で作成されたdebugger.cfg）およびボード（ISSパッケージに含まれる）の構成ファイルをパラメーターとして指定する必要があります。 これを行うには、管理者からコマンドラインを実行し、現在のディレクトリをdebugger \ openocd \ binに変更し、そこからコマンドを実行します

 openocd -f .. \ scripts \ intefrace \ ftdi \ debugger.h -f .. \ scripts \ board \ quark_x10xx_board.cfg 

すべてを正しく行った場合、コマンドはおよそ以下を出力します。

 Info : clock speed 4000 kHz Info : JTAG tap: quark_x10xx.cltap tap/device found: 0x0e681013 (mfg: 0x009, part: 0xe681, ver: 0x0) enabling core tap Info : JTAG tap: quark_x10xx.cpu enabled 

あなたが代わりに持っている場合

 Error: libusb_open() failed with LIBUSB_ERROR_NOT_SUPPORTED 

これは、ドライバーまたはデバッガーの構成に問題があることを意味します。

デバッグシンボルを取得します

前のパートで説明したGalileoのファームウェアアセンブリがメインシステムで実行された場合、この手順をスキップできます。 私にとっては、仮想マシンで発生したため、ソースベースのデバッグでは、ファームウェアのソースコードとデバッグ情報を含むファイルを取得する必要があります。
ディレクトリQuark_EDKII_vX.YZをホームディレクトリからメインOSのデスクトップ上のVMにコピーし、 xdb_remoteスクリプトを使用してIntel Debuggerを起動します（Windowsでは、リンクはメニューStart-> ISS-> Debugger Startup-> Quark SoCにあります ）、 Options-ウィンドウを開きます>ソースディレクトリ... 、最初のタブでルールを作成し、コピーしたディレクトリへの古いパスを新しいものに置き換えます。私の場合は「\ home \ congatec \ Galileo」->「C：\ Users \ Nikolaj \ Desktop」、2番目のタブ同じディレクトリをソースディレクトリリストに追加します。 これらのアクションは両方とも、デバッガーがデバッグされたモジュールのソースコードを個別に見つけるのに役立ちます。

ガリレオに接続

上記の説明に従ってOpenOCDとIntelデバッガーを起動し、Galileoで[リセット]をクリックしてから、デバッガーウィンドウの[接続]ボタンをクリックします。 デバッガーの接続時に停止したモジュールのリストが[アセンブラー]ウィンドウに表示された場合は、問題ありません。ハードウェアデバッグを続行できます。 前の手順でエラーがあるかどうかを確認するには、DXEフェーズ（ボードの再起動後3〜5秒）で停止し、xdb>プロンプトでefi "setsuffix .debug"およびefi loadthisコマンドを入力します。 すべてが正しく行われた場合、デバッグシンボルは正常にロードされ、デバッガは[アセンブラ]タブからソースエディタに移動します。 loadthisへの応答として「システムテーブルが見つかりません」というメッセージが表示された場合は、少し遅れてまたは少し早く実行を停止してみてください。

結論と計画

記事の次の部分では、シンプルなDXEドライバーを作成し、ファームウェアのクイックアセンブリを準備し、この記事で準備したIntelデバッガーと他のデバッグツールの両方を使用してデバッグを試みます。 ご清聴ありがとうございました。次のパートでお会いしましょう。
PS親愛なるUFO、多分今、あなたはプロファイルUEFIハブを追加できますか？ とてもクールだろう。

文学

FTDI USB高速デバイスとJTAG TAPのインターフェース| FTDIアプリケーションノート
アダプター構成のデバッグ| OpenOCDドキュメント
Intel Quark SoC X1000でOpenOCD / GDB / Eclipseを使用したソースレベルのデバッグ| Intelアプリケーションノート