デバッグ アプリケーション プロジェクト

システム デバッガーでサポートされるデザイン フロー

ザイリンクス システム デバッガーを使用したスタンドアロン アプリケーションのデバッグ

このセクションでは、ザイリンクス システム デバッガーを使用してベアメタル アプリケーションをデバッグする方法について説明します。

  1. サンプルの Hello World プロジェクトを作成します。
  2. アプリケーションを選択し、Run > Debug As > Launch On Hardware (Single Application Debug) をクリックします。

システム デバッガーを使用した Linux アプリケーションのデバッグ

  1. Vitis ソフトウェア プラットフォームを起動します。
  2. Linux アプリケーションを作成します。
  3. デバッグするアプリケーションを選択します。
  4. アプリケーションを右クリックし、Debug As > Debug Configuration をクリックします。
  5. Launch on Hardware (Single Application Debug) をクリックし、新しいコンフィギュレーションを作成します。
  6. [Debug Configuration] ダイアログ ボックスで次を実行します。
    1. Target Setup タブをクリックします。
    2. [Debug Type] ドロップダウン リストから Linux Application Debug を選択します。
    3. [Host Name] フィールドに Linux ホスト名または IP アドレスを入力します。
    4. デフォルトでは、tcf-agent が Linux の 1534 ポートで実行されます。tcf-agent を別のポートで実行する場合は、Port フィールドにそのポート番号を入力します。
    5. [Application] タブで Browse をクリックしてプロジェクト名を選択します。Vitis ソフトウェア プラットフォームが自動的にアプリケーションに情報を含めます。

    6. [Remote File Path] フィールドに Linux でアプリケーションをダウンロードするパスを指定します。

    7. アプリケーションに引数が必要な場合は、[Arguments] タブで指定します。

    8. アプリケーションに環境変数を設定する場合は、[Environments] タブで指定します。

    9. Debug をクリックします。標準 I/O 操作を処理する別のコンソールが自動的に開きます。



    10. Terminate ボタンをクリックしてアプリケーションを終了します。

トラブルシューティング

アプリケーションが既に Linux ターゲットに存在する場合に、システム デバッガーでダウンロードされたアプリケーションではなく既存のアプリケーションが使用されるようにする方法
  1. システム デバッガーの [Application] タブで、[Project Name] および [Local File Path] を空のままにします。
  2. [Remote File Path] でリモート アプリケーションのパスを指定し、Debug をクリックします。システム デバッガーに指定のアプリケーションが読み込まれます。

ザイリンクス システム デバッガーを使用した接続およびデバッグ

ザイリンクス システム デバッガーを使用すると、Linux カーネルをデバッグできます。次の手順に従って、ターゲットで実行される Linux カーネルに接続して、ソース コードをデバッグします。

  1. 次のコンフィギュレーション オプションを使用してカーネル ソースをコンパイルします。
    CONFIG_DEBUG_KERNEL=y
    CONFIG_DEBUG_INFO=y
  2. Vitis ソフトウェア プラットフォームを起動します。
  3. Window > Open Perspective > Debug をクリックします。
  4. アプリケーションを右クリックし、Debug As > Debug Configuration をクリックします。
  5. [Debug Configurations] ダイアログ ボックスで Launch on Hardware (Single Application Debug) を選択して New ボタン () をクリックします。
  6. コンフィギュレーションに Zynq_Linux_Kernel_Debug という名前を付けます。
  7. 実行中ステートのプロセッサを使用してデバッグが開始されます。
  8. Pause ボタンをクリックし、プロセッサを一時停止します ()。[Disassembly] モードでデバッグが開始します。
  9. vmlinux シンボル ファイルを両方のプロセッサ コアに追加します。
    1. ARM Cortex-A9 MPCore#0 を右クリックし、Symbol Files をクリックします。
    2. add をクリックし、vmlinux シンボル ファイルを追加します。
    3. OK をクリックします。
    4. ARM Cortex-A9 MPCore#1 を右クリックし、Symbol Files をクリックします。
    5. add をクリックし、vmlinux シンボル ファイルを追加します。
    6. OK をクリックします。
  10. Linux マシンでコードを構築し、Windows でデバッガーを実行する場合は、ソース ルックアップを設定する必要があります。
  11. デバッグ コンフィギュレーション Zynq_Linux_Kernel_Debug を右クリックし、Edit Source Lookup をクリックします。
  12. Add をクリックします。
  13. Add Source ダイアログ ボックスで Path Mapping を選択します。
  14. Add をクリックし、コンパイル パスとローカル ファイル システム パスを追加します。
  15. ソース ファイルが問題なく設定されると、ソース コードをデバッグできるようになります。
  16. [Breakpoints] ビューのツールバーを使用すると、関数ブレークポイントを追加できます。
  17. start_kernel 関数にブレークポイントを追加します。
  18. リセット ボタンをクリックします。Zynq-7000 SoC プロセッサが SD カードからブートされ、カーネル初期化の冒頭で停止します。
    注記: Linux カーネルは常に完全に最適化され、インラインがイネーブルになった状態でコンパイルされます。このため、命令の順番が変わってしまう可能性があるので、コードのステップスルーが正しく動作しないことがあります。さらに、変数の中にコンパイラの最適化で削除されるものがあり、デバッガーで使用できないこともあります。

QEMU でシステム デバッガーを使用したスタンドアロン アプリケーションのデバッグ

  1. Vitis ソフトウェア プラットフォームを起動します。
  2. スタンドアロン アプリケーション プロジェクトを作成します。既存プロジェクトを選択することも可能です。
  3. Debug As > Debug Configurations をクリックします。
  4. Launch on Emulator (Single Application Debug) をダブルクリックして、[Main] タブの Emulation チェック ボックスをオンにして、新しいコンフィギュレーションを作成します。
    注記: Zynq UltraScale+ MPSoC に基づいたハードウェア プラットフォームだけがスタンドアロン アプリケーション デバッグ用に選択されます。


  5. [Debug Configuration] ダイアログ ボックスでは次を設定します。
    1. アプリケーションに引数が必要な場合は、[Arguments] タブで指定します。
    2. アプリケーションに環境変数を設定する場合は、[Environments] タブで指定します。
  6. Debug をクリックします。
  7. [Emulation Console] は、Window > Show View > Other をクリックしても開くことができます。[Emulation Console] は、QEMU で実行されるプログラムとのやり取りに使用できます。STDIN は、qemu% プロンプトの入力ボックスに表示されます。出力は、その入力テキストの上のエリアに表示されます。

システム デバッガーを使用したマルチプロセッサのデバッグ

システム デバッガーの 1 つのデバッグ コンフィギュレーションで複数のプロセッサを同時にデバッグできます。

  1. デザインに含まれるプロセッサ用のアプリケーション プロジェクトを作成します。
  2. アプリケーションを選択し、Debug As > Debug Configurations をクリックします。
  3. Debug Configurations ダイアログ ボックスの左側でコンフィギュレーション タイプ ([Single Application Debug]) を選択し、New ボタン をクリックします。
  4. コンフィギュレーションに Multi_Processor_ZC706_Debug という名前を付けます。
  5. [Target Setup] タブで、適切な設定を選択します。
  6. Debug Type ドロップダウン リストから Standalone Application Debug を選択します。
  7. 接続するターゲットを選択します。この場合、デバッガーを起動する前にターゲットでリセットおよび初期化は実行されません。
  8. 自動的にビットストリームおよび初期化ファイルが設定されるようにするには、[Hardware Platform] ドロップダウン リストから該当するハードウェア プラットフォームを選択します。別のビットストリームおよび初期化ファイルを選択する場合は、Browse ボタンを使用します。

  9. システム全体をリセットする場合は、[Debug Configurations] ウィンドウで Reset entire system をオンにします。
  10. システム リセット後にビットストリームをプログラムする場合は、Program FPGA をオンにします。
  11. PS 初期化ファイルを実行するには、Run ps7_init をオンにします。
    注記: [Summary] ページにシステム デバッガーの処理内容のサマリが表示されます。
  12. Applications タブをクリックし、選択したハードウェア プラットフォームに使用可能なプロセッサを表示します。
  13. 選択したプロセッサにアプリケーションをダウンロードする場合は、Download Application をオンにします。
    注記: プロセッサにプロジェクトが 1 つのみ存在する場合は、Download Application をオンにすると、[Project Name] および [Application Name] フィールドが自動的に設定されます。プロセッサにプロジェクトが複数存在する場合は、Project Name を手動で選択する必要があります。
  14. アプリケーションの main() の前でプロセッサを停止する場合は、Stop at program entry をオンにします。
  15. マルチプロセッサ デバッグを起動する場合は、Debug ボタンをクリックします。

システム デバッガーを使用したリモート ホストの使用

  1. リモート システム環境の設定
    1. デフォルト以外のポート (例: 3122) を使用して hw_server を実行すると、リモート接続がイネーブルになります。次のコマンドを使用して、3122 ポートで hw_server を起動します。
          the hw_server -s TCP::3122
    2. ボードが正しく接続されていることを確認します。
    3. ホスト マシンのコマンド ウィンドウで IP アドレスを確認します。

  2. リモート デバッグ用のローカル システムの設定
    1. Vitis ソフトウェア プラットフォームを起動します。
    2. リモートでデバッグするアプリケーションを選択します。
    3. Debug As > Debug Configurations をクリックします。
    4. 新しいシステム デバッガー コンフィギュレーションを作成します。
    5. [Target Setup] タブで New をクリックして新しいターゲット接続を作成します。

    6. [New Target Connection] ダイアログ ボックスで、ターゲットに接続するリモート ホストに必要な詳細を追加します。
    7. [Target Name]: ターゲットの名前。
    8. [Host]: ホスト マシンの IP アドレスまたは名前。
    9. [Port]: 3121 など、ハードウェア サーバーを起動するポート。
    10. Use Symbol Serverを選択し、アプリケーションをリモートでデバッグ中にソース コード ビューが表示されるようにします。シンボル サーバーには、ハードウェア サーバーと Vitis ソフトウェア プラットフォーム間の橋渡しの役割があります。
    11. OK をクリックします。
    12. 使用可能な接続が 2 つあることがわかります。この場合、remote_zc702_1 がリモート接続です。

    13. 残りのデバッグ設定を選択または追加して、Debug をクリックします。

OS 認識デバッグ

JTAG を使用した OS 認識デバッグ機能を使用すると、現在実行中のプロセッサまたはスレッド、プロセスまたはスレッド特有のスタック トレース、レジスタ、変数表示などの OS 特有の情報を可視化できます。OS 認識をイネーブルにすると、プロセッサ コア上で実行中の OS と OS 上で実行中のプロセス/スレッドを同時にデバッグできます。

OS 認識デバッグのイネーブル

このセクションでは、Vitis IDE を使用して、SD カードから Linux を実行する Zynq ボードの OS 認識デバッグを設定する方法について説明します。ボードへの JTAG 接続を設定し、Linux カーネルをビルドし、SD カードからそれをブートする方法は理解していることを前提としています。カーネル デバッグの設定方法は、ザイリンクス システム デバッガーを使用した接続およびデバッグ を参照してください。

  1. 次のコンフィギュレーション オプションを使用してカーネル ソースをコンパイルします。
    CONFIG_DEBUG_KERNEL=y
    CONFIG_DEBUG_INFO=y
  2. Vitis ソフトウェア プラットフォームを起動します。
  3. Window > Open Perspective > Debug をクリックします。
  4. Debug As > Debug Configurations をクリックします。
  5. [Debug Configurations] ダイアログ ボックスで Single Application Debug を選択して New ボタン () をクリックします。
  6. Debug をクリックします。
  7. 実行中ステートのプロセッサを使用してデバッグが開始されます。
  8. プロセッサ コンテキストの [Debug] ビューで Enable Linux OS Awareness オプションをオンにします。
  9. 表示されるメニューからは、次も実行できます。
    • Refresh OSA Processes: オンにすると、実行中のプロセスのリストが更新されます。
    • Auto refresh on exec: オンにすると、実行中のすべてのプロセスが更新され、Debug ビューに表示されます。オフにすると、新しいプロセスは [Debug] ビューに表示されません。
    • Auto refresh on suspend: オンにすると、プロセッサが一時停止されるたびに、すべてのプロセッサが再同期化されます。オフの場合、現在のプロセスのみが再同期化されます。
    • Linux OSA File Selection: オンにすると、シンボル ファイルを変更できます。
  10. OS 認識デバッグは ザイリンクス システム デバッガー (XSDB) で -osa コマンドを使用してもイネーブルにできます。
    osa -file <symbol-file> -fast-step -fast-exec

プロセス/スレッド レベルのデバッグ

OS 認識デバッグがイネーブルになると、[Debug] ビューが Linux カーネルで実行されるプロセスのリストでアップデートされます。OS 認識デバッグをイネーブルにする方法は、OS 認識デバッグのイネーブル を参照してください。プロセッサ コアが停止するとプロセス リストが初めてアップデートされ、この後はダイナミックにアップデートされていきます (新しいプロセスがリストに追加され、停止されたプロセスが削除されます)。

プロセス コンテキストを展開すると、プロセスの一部であるスレッドを確認できます。



シンボル ファイルをプロセス コンテキストに追加すると、ソース レベルのデバッグをイネーブルにして、スタック トレース変数を確認できます。ソース レベルのブレークポイントも設定できます。または、パス マップを設定してもソース レベルのデバッグをイネーブルにできます。デバッガーはパス マップ設定を使用して、システムに含まれるすべての実行ファイルおよび共有ライブラリのシンボル ファイルを検索およびロードします。

注記: パス マップは、シンボルおよびソース ルックアップの両方に使用されます。

main () からプロセスをデバッグ

main() から新しいプロセスをデバッグするには、プロセス開始前にグローバル ブレークポイントを設定します (特定のターゲット/コンテキストに対しては設定しません)。シンボル ファイルがパス マップ設定に基づいて読み込まれるので、開始前に新しいプロセスに該当するエントリがあるはずです。

main() からプロセスをデバッグする手順は、次のとおりです。

  1. [Project Explorer] ビューでプロジェクトを選択します。
  2. Debug As > Debug Configurations をクリックします。[Debug Configurations] ダイアログ ボックスが表示されます。
  3. Path Map タブをクリックして選択したデバッグ コンフィギュレーションのパス マップを設定します。パス マップがあると、ソース レベルのデバッグをイネーブルにしやすくなります。デバッガーはパス マップ設定を使用して、システムに含まれるすべての実行ファイルおよび共有ライブラリのシンボル ファイルを検索およびロードします。
  4. Linux アプリケーションのソース ファイルにライン ブレークポイントを設定するか、main() に関数ブレークポイントを設定します。新しいプロセスが開始するたびに、デバッガーはプロセスのシンボルをチェックして、ソース ファイルまたは main() 関数がシンボルにある場合はプロセスにブレークポイントを設定します。
  5. ターミナルからアプリケーションを実行します。
  6. ブレークポイントに達すると、Debug ビューがそのプロセスの情報で更新されます。
  7. [Debug] ビューには、ファイル、関数、およびブレークポイントの行の情報も表示されます。スレッドがコア上で実行されている場合は、スレッド ラベルに CPU コア名が含まれます。
  8. ステップ イン、ステップ アウト、変数、スタック トレース、およびレジスタの監視など、ソース レベルのデバッグを実行できます。バイナリ パスのターゲット側パスにはマウント ポイント パスが含まれません。これは既知の制限です。たとえば、/mnt にマウントされている SD カードにプロセスがある場合、デバッガーではそのファイルが<filename> と表示され、/mnt/<filename> とは表示されません。

ロード可能なカーネル モジュールのデバッグ

カーネル モジュールをデバッグするには、モジュール名がそのモジュールのシンボル ファイルにマップされるようにパス マッピングを設定します。ロード可能なモジュールを確認するには、Debug ビューで Kernel を選択し、Modules ビューを確認します。カーネル モジュールは、ファイル パス別ではなく、名前別にリストされます。

カーネル モジュールをデバッグする手順は、次のとおりです。

  1. Project Explorer ビューでプロジェクトを選択します。
  2. Debug As > Debug Configurations をクリックします。[Debug Configurations] ダイアログ ボックスが表示されます。
  3. Path Map タブをクリックして選択したデバッグ コンフィギュレーションのパス マップを設定します。
  4. Add をクリックしてカーネル モジュールを挿入します。
  5. 関数またはライン ブレークポイントを挿入して、コアを実行します。ブレークポイントに到達すると、[Debug] ビューがすべての情報を含めてアップデートされます。
  6. 別のプロセスまたはスレッド レベルのデバッグの場合と同様、ブレークポイントの挿入、ステップ イン、ステップ アウト、変数の監視、スタック トレース、またはその他のソース レベルのデバッグ タスクを実行できます。

Xen 認識デバッグ

Xen 認識デバッグを使用すると、異なるドメイン (Dom-0 および Dom-Us)、各ドメインの仮想プロセッサ (VCPU) などのハイパーバイザー特有の情報がわかりやすく表示されます。

この機能は、次の Xen コンポーネントをデバッグできるようにします。

  • ハイパーバイザー
  • Dom-0/Dom-U カーネル
  • Dom-0/Dom-U ユーザー空間プロセス
  • Dom-U スタンドアロン アプリケーション

Xen 認識のイネーブル

このセクションでは、Vitis IDE を使用して、SD カードから Linux を実行する Zynq UltraScale+ MPSoC デバイスの Xen 認識デバッグを設定する方法について説明します。次の要件があらかじめ満たされていることを前提とします。

  • Xen および Dom-0 を実行する ZCU102 ボードを持っている。
  • Xen シンボル ファイル (xen-syms) を持っている。
Xen および Dom-0 をブートする方法については、『PetaLinux ツール資料: リファレンス ガイド』 (UG1144) を参照してください。
  1. Vitis IDE を起動します。
  2. Window > Open Perspective > Debug をクリックします。
  3. Debug As > Debug Configurations をクリックします。
  4. [Debug Configurations] ダイアログ ボックスで Launch on Hardware (Single Application Debug) を選択します。
  5. New () をクリックします。
  6. Attach to running target デバッグ タイプを選択して Debug をクリックします。実行中ステートのプロセッサを使用してデバッグが開始されます。
  7. Cortex-A53 #0 target を右クリックして Symbol Files をクリックします。
  8. シンボル ファイル (xen-syms) を選択します。
  9. OS awareness チェック ボックスをオンにします。

デバッグ ハイパーバイザー

  1. Xen および Dom-0 をブートします。Xen および Dom-0 をブートする方法については、『PetaLinux ツール資料: リファレンス ガイド』 (UG1144) を参照してください。
  2. Xen シンボル ファイルの OS 認識デバッグをイネーブルにして、Xen 認識をイネーブルにします。シンボル ファイルがプロセス コンテキストに追加され、ソース レベルのデバッグをイネーブルにします。Xen 認識をイネーブルにする方法は、Xen 認識のイネーブル を参照してください。
  3. OS 認識デバッグがイネーブルになると、[Debug] ビューが Linux カーネルで実行されるプロセスのリストでアップデートされます。プロセッサ コアが停止するとプロセス リストが初めてアップデートされ、この後はダイナミックにアップデートされていきます (新しいプロセスがリストに追加され、停止されたプロセスが削除されます)。
  4. Edit Source Lookup Path をクリックし、選択したデバッグ コンフィギュレーションのパス マップを設定します。デバッガーはパス マップを使用して、システムに含まれるすべての実行ファイルおよび共有ライブラリのシンボル ファイルを検索およびロードします。

    注記: パス マップは、シンボルおよびソース ルックアップの両方に使用されます。
  5. ブレークポイントを追加するか、コアを一時停止します。ブレークポイントに到達すると、[Debug] ビューがすべての情報を含めてアップデートされます。
  6. これで、ブレークポイントの挿入、ステップ イン、ステップ アウト、変数の監視、スタック トレース、またはその他のソース レベルのデバッグ タスクを実行できるようになりました。

Dom-0/Dom-U カーネルのデバッグ

  1. Xen および Dom-0 をブートします。Xen および Dom-0 をブートする方法については、『PetaLinux ツール資料: リファレンス ガイド』 (UG1144) を参照してください。
  2. Xen シンボル ファイルの OS 認識デバッグをイネーブルにして、Xen 認識をイネーブルにします。シンボル ファイルがプロセス コンテキストに追加され、ソース レベルのデバッグをイネーブルにします。Xen 認識をイネーブルにする方法は、Xen 認識のイネーブル を参照してください。
  3. Dom-0 カーネルをデバッグします。
    1. Dom-0 VCPU コンテキストに対して、[Debug] ビューで Linux シンボル ファイルの OS 認識をイネーブルにします。OS 認識デバッグの詳細は、OS 認識デバッグ を参照してください。
    2. Dom-0 VCPU#0 コアを一時停止します。これで、ブレークポイントの挿入、ステップ イン、ステップ アウト、変数の監視、スタック トレース、またはその他のソース レベルのデバッグ タスクを実行できるようになりました。

  4. Dom-U カーネルをデバッグします。
    1. ゲスト Linux イメージを Dom-0 ファイル システムにコピーします。
    2. Dom-U ゲストを作成します。
    3. Dom-U VCPU コンテキストに対して、[Debug] ビューで Linux シンボル ファイルの OS 認識をイネーブルにします。OS 認識デバッグの詳細は、OS 認識デバッグ を参照してください。
    4. Dom-U VCPU#0 コアを一時停止します。これで、ブレークポイントの挿入、ステップ イン、ステップ アウト、変数の監視、スタック トレース、またはその他のソース レベルのデバッグ タスクを実行できるようになりました。

Dom-0/Dom-U ユーザー空間プロセスのデバッグ

  1. Xen および Dom-0 をブートします。Xen および Dom-0 をブートする方法については、『PetaLinux ツール資料: リファレンス ガイド』 (UG1144) を参照してください。
  2. Xen シンボル ファイルの OS 認識デバッグをイネーブルにして、Xen 認識をイネーブルにします。シンボル ファイルがプロセス コンテキストに追加され、ソース レベルのデバッグをイネーブルにします。Xen 認識をイネーブルにする方法は、Xen 認識のイネーブル を参照してください。
  3. Linux アプリケーション プロジェクトを作成します。Linux アプリケーション プロジェクトを作成する方法については、Linux アプリケーション プロジェクトの作成 を参照してください。
  4. ホスト ドメイン (Dom-0) の仮想 CPU (VCPU#) のコンテキストをデバッグするには、Linux で実行されるアプリケーションのシンボル ファイルを追加して、Dom-0 ユーザー空間プロセスを設定します。
  5. Dom-U ユーザー空間プロセスを設定します。
    1. ゲスト Linux イメージを Dom-0 ファイル システムにコピーします。
    2. 準仮想化ネットワークを使用して Linux ゲストを作成します。
          name = "guest 0"
          kernel = "/boot/Image"
          extra = "console=hvc0 rdinit=/sbin/init"
          memory = 256
          vcpus = 2
          vif = [ 'bridge=xenbr0' ]
    3. ゲスト ドメイン (Dom-U) の仮想 CPU (VCPU#) のコンテキストをデバッグするには、Linux で実行されるアプリケーションのシンボル ファイルを追加します。
  6. シンボル ファイルが設定されると、ブレークポイントを挿入、ステップ イン、ステップ アウト、変数の監視、スタック トレース、またはその他のソース レベルのデバッグ タスクを実行できます。

Dom-U スタンドアロン アプリケーションのデバッグ

  1. 新しいスタンドアロン ハイパーバイザー ゲスト アプリケーションを作成します。
    1. File > New > Application Project をクリックします。New Application Project ウィザードが表示されます。
      注記: または、File > New > Project をクリックして New Project ウィザードを開き、Xilinx > Application Project を選択して Next をクリックしても、同じ操作を実行できます。
    2. [Project Name] にプロジェクト名を入力します。
    3. プロジェクトのディレクトリを指定します。[Location] に表示されているデフォルトのディレクトリを使用するには、Use default location をオンのままにします。デフォルト以外のディレクトリを使用する場合は、このチェック ボックスをオフにし、ディレクトリ名を入力または選択します。
    4. [OS Platform] からは、コードを記述するオペレーティング システムを選択できます。standalone をクリックします。
      注記: この選択により、次のページに表示されるテンプレートとプロジェクトで使用可能なサポート コードが変わります。
    5. プラットフォームを選択するウィンドウで Create a New Platform from Hardware (XSA) をクリックします。zcu102 design を選択して Next をクリックします。
    6. CPU と OS を選択します。
    7. Next をクリックして [Templates] ページへ進みます。
    8. [Hypervisor Guest] ドロップダウン リストから Yes をクリックし、Xen を実行するのに適した定義済みリンカー スクリプトを使用してアプリケーションを作成します。
    9. ボード サポート パッケージまたはドメインを指定します。新しいカスタマイズ可能なドメインを作成するか、既存ドメインを選択できます。ウィザードで作成されるドメインの hypervisor_guest パラメーターが true に設定されます。stdin および stdoutpsu_uart_1 を指定するようにする必要もあります。
    10. Next をクリックして [Templates] ページに進みます。
    11. Vitis ソフトウェア プラットフォームではサンプル アプリケーションが提供されており、Templates ページで選択してプロジェクトの作成に使用できます。Description に選択したサンプル アプリケーションの簡単な説明が表示されます。プロジェクトにサンプル アプリケーションを使用すると、Vitis ソフトウェア プラットフォームで必要なソースおよびヘッダー ファイルおよびリンカー スクリプトが作成されます。
    12. 使用するテンプレートを選択します。空のプロジェクトを作成する場合は、 Empty Application を選択します。プロジェクトの作成後に C ファイルを追加できます。
    13. Finish をクリックし、アプリケーション プロジェクトとボード サポート パッケージ (存在しない場合) を作成します。
      注記: ザイリンクスでは、makefile に慣れている場合を除き、標準の Make C/C++ ではなく Managed Make フローを使用することをお勧めしています。
  2. 新しく作成したハイパーバイザー ゲスト スタンドアロン アプリケーションをビルドして .bin ファイルを生成します。このファイルは、Xen を使用するために必要です。
  3. Xen および Dom-0 をブートします。Xen および Dom-0 をブートする方法については、『PetaLinux ツール資料: リファレンス ガイド』 (UG1144) を参照してください。
  4. Xen シンボル ファイルの OS 認識デバッグをイネーブルにして、Xen 認識をイネーブルにします。シンボル ファイルがプロセス コンテキストに追加され、ソース レベルのデバッグをイネーブルにします。Xen 認識をイネーブルにする方法は、Xen 認識のイネーブル を参照してください。
  5. アプリケーションを Dom-0 ファイル システムにコピーします。
  6. Xen コンフィギュレーション ファイルを使用してゲスト ドメイン hello を作成します。
        name = "hello"
        kernel = "/boot/hello.bin"
        memory = 8
        vcpus = 1
        cpus = [1]
        irqs = [ 54 ]
        iomem = [ "0xff010,1" ]
  7. Dom-U VCPU#0 コアを一時停止します。これで、ブレークポイントの挿入、ステップ イン、ステップ アウト、変数の監視、スタック トレース、またはその他のソース レベルのデバッグ タスクを実行できるようになりました。

自己再配置プログラムのデバッグ

システム デバッガーでは、U-Boot のような自己再配置プログラムのソース レベル デバッグがサポートされています。自己再配置プログラムとは、ランタイム中にコードおよびデータ セクションを再配置するプログラムです。これらのファイルのデバッグ情報には、プログラム セクションがどこに再配置されたかの詳細は含まれません。そのため、プログラムの再配置先のアドレスをデバッガーに提供する必要があります。これは、次の 2 つの方法で実行できます。

  1. システム デバッガーの実行コンフィギュレーションをアップデートし、プログラム セクションの再配置先アドレスを指定します。
    1. Debug As > Debug Configurations をクリックし、システム デバッガーの実行コンフィギュレーションを開始します。
    2. Application タブをクリックして、ダウンロードするアプリケーションを選択します。
    3. This is a self-relocating application をオンにします。
    4. Relative address to which the program sections are relocated テキスト ボックスにすべてのプログラム セクションを再配置するアドレスを入力します。
    5. デバッグ コンフィギュレーションを起動します。これで、ランタイム中にプログラム セクションが再配置されたときに、デバッガーに再配置されたセクションのソース レベル デバッグをサポートするのに十分な情報が供給されます。

    注記: この方法は、デバッグ コンフィギュレーションの Target Setup タブの Debug TypeStandalone に設定した場合にのみサポートされます。
  2. また、XSDB で memmap コマンド使用しても、プログラム セクションの再配置先アドレスを指定できます。XSDB の memmap コマンドを使用すると、デバッガーにシンボル ファイルを追加できます。これは、ターゲット上で既に実行中のアプリケーションをデバッグする際に便利です。たとえば、フラッシュからブートする場合などに便利です。再配置可能な ELF ファイルの場合は、-relocate-section-map オプションを使用して再配置先アドレスを指定します。
    xsdb% targets 2
     1 APU
       2 ARM Cortex-A9 MPCore #0 (Suspended)
       3 ARM Cortex-A9 MPCore #1 (Suspended)
     4 xc7z020
    xsdb% targets 2
    xsdb% memmap -reloc 0x3bf37000 -file u-boot
    
    xsdb% stop
    Info: ARM Cortex-A9 MPCore #0 (target 2) Stopped at 0x3ff7b478 (Suspended)
    xsdb% bt
     0 0x3ff7b478 __udelay()+1005809800: lib/time.c, line 91
     1 0x3ff7b4ac udelay()+1005809696: lib/time.c, line 104
     2 0x3ff5d878 genphy_update_link()+1005809860: drivers/net/phy/phy.c, line 250
     3 0x3ff5df84 m88e1118_startup()+1005809712: drivers/net/phy/marvell.c, line 356
     4 0x3ff5d154 zynq_gem_init()+1005810192: drivers/net/zynq_gem.c, line 402
     5 0x3ff7dc58 eth_init()+1005809720: net/eth.c, line 886
     6 0x3ff7e0e4 net_loop()+1005809728: net/net.c, line 407
     7 0x3ff46330 netboot_common()+1005809972: common/cmd_net.c, line 230
     8 0x3ff46520 do_tftpb()+1005809708: common/cmd_net.c, line 33
     9 0x3ff5295c cmd_process()+1005809824: common/command.c, line 493
     10 0x3ff5295c cmd_process()+1005809824: common/command.c, line 493
     11 0x3ff3b710 run_list_real()+1005811444: common/cli_hush.c, line 1656
     12 0x3ff3b710 run_list_real()+1005811444: common/cli_hush.c, line 1656
     13 0x3ff3be3c parse_stream_outer()+1005811244: common/cli_hush.c, line 2003
     14 0x3ff3be3c parse_stream_outer()+1005811244: common/cli_hush.c, line 2003
     15 0x3ff3b008 parse_string_outer()+1005809872: common/cli_hush.c, line 3254
     16 0x3ff3b6b8 run_list_real()+1005811356: common/cli_hush.c, line 1617
     17 0x3ff3b6b8 run_list_real()+1005811356: common/cli_hush.c, line 1617
     18 0x3ff3be3c parse_stream_outer()+1005811244: common/cli_hush.c, line 2003
     19 0x3ff3be3c parse_stream_outer()+1005811244: common/cli_hush.c, line 2003
     20 0x3ff3afd0 parse_string_outer()+1005809816: common/cli_hush.c, line 3248
     21 0x3ff5140c do_run()+1005809740: common/cli.c, line 131
     22 0x3ff5295c cmd_process()+1005809824: common/command.c, line 493
     23 0x3ff5295c cmd_process()+1005809824: common/command.c, line 493
     24 0x3ff3b710 run_list_real()+1005811444: common/cli_hush.c, line 1656
     25 0x3ff3b710 run_list_real()+1005811444: common/cli_hush.c, line 1656
     26 0x3ff3be3c parse_stream_outer()+1005811244: common/cli_hush.c, line 2003
     27 0x3ff3be3c parse_stream_outer()+1005811244: common/cli_hush.c, line 2003
     28 0x3ff3b008 parse_string_outer()+1005809872: common/cli_hush.c, line 3254
     29 0x3ff3b6b8 run_list_real()+1005811356: common/cli_hush.c, line 1617
     30 0x3ff3b6b8 run_list_real()+1005811356: common/cli_hush.c, line 1617
     31 0x3ff3be3c parse_stream_outer()+1005811244: common/cli_hush.c, line 2003
     32 0x3ff3be3c parse_stream_outer()+1005811244: common/cli_hush.c, line 2003
     33 0x3ff3afd0 parse_string_outer()+1005809816: common/cli_hush.c, line 3248
     34 0x3ff39ab4 main_loop()+1005809724: common/main.c, line 85
     35 0x3ff3c4f4 run_main_loop()+1005809672: common/board_r.c, line 675
     36 0x3ff73b54 initcall_run_list()+1005809716: lib/initcall.c, line 27
     37 0x3ff3c66c board_init_r()+1005809676: common/board_r.c, line 908
     38 0x3ff3837c clbss_l()+1005809688: arch/arm/lib/crt0.S, line 174
     39 unknown-pc