インテリジェント・システムと組込みデバイス向けソフトウェア開発ツールの使用法

この記事は、インテル® デベロッパー・ゾーンに掲載されている「How to use Software Development Tools Targeting Intelligent Systems and Embedded Devices」 (http://software.intel.com/en-us/articles/intel-system-studio-tips-and-tricks) の日本語参考訳です。

概要

組込みプラットフォームとインテリジェント・システムの形状とサイズはさまざまです。そのほとんどは、たくさんのハードウェア・アーキテクチャーを使用するヘテロジニアスな SoC (システムオンチップ) を採用しています。多様な構成のシステム・ソフトウェア・スタックのカスタマイズとアプリケーション開発には、多様なソフトウェア・スタックのクロス開発に対応できる柔軟なアプローチと開発ツールが必要です。そして、ソフトウェア開発ツールには、スループットを最適化し、優先度の高いプロセスを処理する実装アプローチが求められます。

開発するインテリジェント・システムが、省電力のインテル® Atom™ プロセッサー・ベースの小規模なリアルタイムのカスタム組込み Linux* であっても、個々のタスクに対してプロセッサー・コアが予約されているインテル® Xeon™ プロセッサー・ベースのマルチソケットであっても、組込みソフトウェア開発の基本的な要件が適用されます。そのため、ハードウェア・プラットフォームとデバイスドライバーに関する深い洞察、sysroot ベースのソリューションをサポートする柔軟なクロスビルド環境、そして一般的なクロスビルド環境への統合オプションがあったほうが望ましいでしょう。

この記事は、インテル® アーキテクチャーをターゲットにする際に適切な開発環境を構築できるように、特定のニーズにあったカスタム開発環境を構築する上での注意事項とソリューションについて説明します。

はじめに

過去数年にわたり、組込み市場では、従来の特定の機能を提供する単体のシステムに代わり、新たに登場したインテリジェント・システムの普及が進んだことで組込みデバイスの活用の幅が変わりつつあります。これは、デバイス能力の向上とデバイス間の相互作用の増加をもたらし、その結果、より優れたパフォーマンス、クラウドサービス、新しいデバイスをサポートするソフトウェア・テクノロジーとツールが求められるようになりました。新しいデバイスは安全性、接続性、管理面において優れています。IDC* などの一部の市場調査会社では、新たに登場した “インテリジェント・システム” を新しい組込み分野として識別しています。従来の組込み分野における SoC (システムオンチップ) の採用増加と新しいインテリジェント・システム分野の登場により、開発者とツールベンダーは、設計からコード生成、デバッグ、システム・パフォーマンス解析に至るまでの開発プロセス全体を見直す必要に迫られています。

組込みデバイス向けシステム・ソフトウェア・スタックを開発する際、まずは最適な開発環境の構成について考えます。これは、組込みシステム向けソフトウェア開発へのアプローチを選択する上でも役立ちます。この記事では、x86 またはインテル® アーキテクチャー・ベースのアプリケーション・プロセッサーを使用する SoC の設計について説明します。ターゲット・アプリケーション・プロセッサーのアーキテクチャーに類似した開発システムを使用することで利点が得られ、選択肢も広がります。

従来どおり開発ホストでネイティブ・アプリケーションを開発してターゲットデバイスに展開することも、ハイパーバイザーにより仮想マシンで完全なクロス開発を行うことも、また物理ターゲットデバイスや sysroot/chroot ベースのビルド環境にリモート接続してデバッグを行うこともできます。この記事では、これらの選択肢についても触れます。

インテル® アーキテクチャー・ベースの組込みシステムで最もよく使用されているオペレーティング・システムの 1 つは、カスタム Linux* です。カスタム Linux* は、主要な Linux* ディストリビューション・ベースのものから、独自に構築されたものまでさまざまです。Wind River* Linux*、Yocto Project*、Android* のような組込みモバイル・コンピューティング・アプリケーション向けの Linux* ディストリビューションの役割は、ますます重要になっています。多くの場合、組込み設計では、少なくともソフトウェア・スタックの一部でリアルタイム要件が発生します。そのため、リアルタイム要件が発生するソフトウェア・スタックのコンポーネントを分離し、それ以外のコンポーネントとの依存性を最小限に抑えることが、組込みシステム・ソフトウェアの開発と定義において重要な課題です。

さらに、SoC では、すべてのプラットフォーム・コンポーネントの相互作用を理解することが極めて重要です。特別な GPU 機能やマイクロエンジン、そしてプラットフォーム上のその他のハードウェア・アクセラレーターを利用するデバイスドライバーを開発したり、最近の小さなフォームファクターのデバイスで利用されるさまざまなワイヤレス接続向けにソフトウェア・インターフェイスを設計することもあるでしょう。いずれの場合も、異なるプラットフォーム・コンポーネント間で正しい変数値が受け渡しされるように、メッセージのタイミングを解析することが、プラットフォーム・ソフトウェア・スタックの安定性を図る上で重要です。容易にそして総合的にデバイスの構成レジスターへアクセスできるようにすることで、デバイスドライバーの開発とプラットフォーム・コンポーネント間の相互作用のタイミング制御も簡単になります。

組込みソフトウェア開発プロジェクトに初めて取り掛かる場合、これらの要件は分かりづらく、構成の定義よりも個々の要件の複雑さに囚われがちです。この記事では、組込み開発プロジェクトに取り掛かる際の考慮事項も説明します。

1. 組込みデバイスとインテリジェント・システムにおけるインテル® アーキテクチャー

x86 アーキテクチャーは、その登場以来、組込み分野において重要な役割を果たしてきました。過去 30 年以上にわたって、AMD*、ST Microelectronics*、General Dynamics*、そしてインテルをはじめとする多数の企業が組込み市場向けにさまざまな高集積設計を提供してきました。近年、組込み市場では、ソフトウェア開発者のニーズが変化し、より柔軟なソフトウェア開発環境への要求が高まっています。現代の通信 (M2M およびクラウド・インフラストラクチャー) では、すべてにおいて高度に集積化された計算能力が必要とされるため、クラウドおよびサーバー・インフラストラクチャーでも組込みドメインの活用が進み、従来の組込みと非組込みの境界はなくなりつつあります。

図 1: 組込みデバイスからインテリジェント・システムへ変化

インテル® Atom™ プロセッサーは、画像印刷、産業制御システム、デジタル署名システム、店舗販売時点情報管理 (POS) 端末、医療デバイス、車載システム、デジタル監視システム、IPTV、ネットワーク・サービス・ゲートウェイ、家庭用エネルギー管理システムなどで幅広く使用されています。多様な x86 ベースのインフラストラクチャーとの互換性と省電力の両方が求められるすべての組込み使用ケースに、インテル® Atom™ プロセッサーは最適です。

AMD* Opteron* シリーズ、インテル® Core™ プロセッサー・ファミリー、インテル® Xeon® プロセッサー・ファミリーは、サーバー、産業、ネットワーク、通信、およびメディア・インフラストラクチャーなどで広範に使用されています。

あらゆるものがネットワークに接続された “Internet of Things (もののインターネット)” で動作する組込みデバイスとインテリジェント・システムは、多くの開発マシンや PC と同じアーキテクチャーをベースにしています。そのため、各種デバイスの OEM は、同じソフトウェア・エコシステムを利用してコストを抑えつつ、短期間に開発およびアップグレードを行うことができます。

図 2: インテリジェント・システムの分野

しかし、統合がますます進み、ヘテロジニアスなマルチコアシステムが増加するのに伴って、インテル® アーキテクチャー向け組込みソフトウェア開発ソリューションの既存のエコシステムではいくつかの課題が生じます。ここでは、これらの課題とその対処方法について述べます。

2. インテリジェント・システムのクロス開発

ビルド環境を定義する際、まず最初に開発に使用するクロスビルド環境ツールを決定します。商用のリアルタイム・オペレーティング・システム (RTOS) を使用する場合、OS ベンダーから提供される基本開発ツールを利用できます。商用 RTOS の例として、Green Hills* Software の Integrity*、Wind River* の VxWorks*、MentorGraphics* の Nucleus*、QNX* などがあります。これらはすべて独自の開発ツールを提供しており、ほかのベンダーのユーティリティーによって拡張することができます。

Linux* ベースのターゲット OS を使用する場合は、リアルタイム・スケジューラーの有無にかかわらず、幅広い選択肢があります。独自のクロスビルド・ツールを構築したり、buildroot/chroot ラッパー内にターゲット OS の完全なイメージを作成したり、組込み市場向けの特定の Linux* ディストリビューションに付属するクロスビルド環境を利用することができます。

では、具体的にクロス開発向け GNU* ツールを選択する上で考慮すべきことを見ていきましょう。

組込み向け開発ツールの使用法について、次の 3 つのマシン環境を区別する必要があります。

ツールを構築するビルドマシン
ツールを実行するホストマシン
ツールでコードを生成する際に対象とするターゲットマシン

実際に 3 つのシステムが必要になることはまれです。ほとんどの場合、ビルドマシンとホストマシンは同じです。そのため、開発ホストマシンと開発ターゲットマシンを設定するだけで済みます。

図 3: 基本クロス開発ツールの設定

完全なツールスイートは次のコンポーネントで構成されます。

コンパイラー: さまざまなコンパイラーがあります。Linux* ターゲットで最も一般的なのは GNU* プロジェクトの GCC* コンパイラーと G++ コンパイラーです。これらのコンパイラーは、インテル® C++ コンパイラーで拡張することができます。場合によっては、これらの代わりにインテル® C++ コンパイラーでアプリケーション全体のビルドを行ったほうが良いこともあります。ここで選択すべきことは、ネイティブ GCC* ビルド用のコンパイラーとクロス環境向けのツールスイートに含まれるコンパイラーのどちらを利用するかです。
ビルド処理のバックエンド・コンポーネント: コンパイラーのほかにも、アセンブラー、リンカー、出力形式の変換ユーティリティーなど、さまざまなビルド処理のバックエンド・ツールがあります。Linux* では、これらは GNU* Binutils* に含まれます。
ライブラリー:
- C ライブラリーには主要なライブラリー・ファイルが含まれており、ユーザー空間のアプリケーション開発に使用される POSIX* API を実装しています。C ライブラリーは、システムコールによりカーネルと連携して、高レベルのサービスを提供します。GLIBC* (http://www.gnu.org/software/libc/) は GNU* プロジェクトの C ライブラリーです。Embedded GLIBC (http://eglibc.org) は、組込みシステム向けに最適化された GNU* C ライブラリー (GLIBC) で、ソースおよびバイナリーレベルで GLIBC* との互換性を保持しつつフットプリントを減らし、クロスコンパイルとクロステストをサポートします。uClibc (http://uclibc.org) の C ライブラリーは、フットプリントが非常に小さく、フラッシュ領域やメモリー・フットプリントが問題になる場合の選択肢となります。このライブラリーは C コンパイラーと特殊な関係にあるため、カスタム・ツール・スイートを生成するときに選択する必要があります。いったんツールを構築したら、通常、ほかのライブラリーに変更することはできません。
- C ライブラリーのほかに、最適化および簡素化された信号処理、メディア処理、暗号化ルーチンを実装するためのライブラリーがあります。例えば、Vector Signal Image Processing Library VSIPL (http://www.vsipl.org/)、インテル® インテグレーテッド・パフォーマンス・プリミティブ (インテル® IPP)、インテル® マス・カーネル・ライブラリー (インテル® MKL) などです。
パフォーマンスおよび電力解析ツール: 組込みシステムでは通常、特定のタスクで最大限のパフォーマンスを引き出しつつ、消費電力またはバッテリー使用量を抑えることが求められるため、クロス開発ツールのソフトウェア・チューニングや解析ツールの役割はますます重要になります。これらのツールにはさまざまな選択肢があり、その使用ケースは広範にわたります。詳しくは後述します。
デバッガー: 高い信頼性が求められる多様な組込みシステムにまだ不慣れな開発者は、デバッガーの重要性を過小評価しがちです。デバッガーには、メモリーおよびコードの正当性検証ツール、高水準言語で記述されたアプリケーションのデバッグツール、システム・ソフトウェア・デバッガーの 3 種類があります。最後の 2 つは、ソフトウェア・スタック・コンポーネントのリアルタイム・デバッグに使用します。ヘテロジニアスなマルチコア SoC チップの複雑な相互作用により、新たに 4 つ目のデバッグツールとして見直されているのがインストルメンテーション・ベースのイベント・トレース・ユーティリティーです。

これらのツール群を含むビルドツール構成だけが完全なツールスイートと見なされます。

開発ホストおよび OS がターゲット・アーキテクチャーとその OS に類似している場合、最も簡単なアプローチは buildroot (http://www.buildroot.net) です。このアプローチの概念は、完全なカスタム組込み Linux* ビルド環境があれば、カスタム OS イメージを作成できることです。この OS イメージにビルドツールを含めることで、自動的にビルド環境も得られます。そして、chroot (http://www.linux.org/article/view/chroot-access-another-linux-from-your-current-linux-) を使って仮想 OS イメージ用の仮想ブート環境を作成することで、標準の Linux* ホスト上の保護された仮想ラッパーで新しい組込み Linux* ビルド環境を実行することができます。インテル® アーキテクチャー向けの開発では、開発ホストとターゲットが類似している場合、実際の仮想マシンのオーバーヘッドなしでこれらのことを行えます。

別のアプローチは、–sysroot オプションを指定して使用する C ライブラリー、ヘッダー、開始オブジェクト、その他の共有オブジェクトとそれらの場所をコンパイラーに知らせ、カスタム・クロスビルド用の binutils と gcc ツールを生成します。このアプローチは、インテル® アーキテクチャーをターゲットにする場合だけでなく、ほかのアーキテクチャーをターゲットにする場合にも利用できます。一般的な GNU* ベースのクロスビルド環境はすべて、これに似たアプローチを採用しています。

独自のクロスビルド GNU* ツールセットを作成することは、多くの場合、独自のカスタム Linux* プラットフォームを構築することに直結しています。カスタム Linux* を作成する 1 つのアプローチとして、OpenEmbedded* (http://www.openembedded.org) と Bitbake* ユーティリティーを利用できます。独自のクロスビルド GNU* ツールの作成には、Poky Linux* (http://pokylinux.org) を利用できます。

OpenEmbedded* や Yocto Project* などの完全な組込み Linux* フレームワークはこれらを基にしています。

独自のフレームワークを作成するよりも、既存のフレームワークを利用したほうが良いことも多々あります。OpenEmbedded* と Yocto Project* に加えて、Code Sourcery*、Wind River*、MontaVista*、Timesys* からもさまざまなフレームワークが提供されているので確認してみてください。

これで、インテル® アーキテクチャー向けの開発に使用する、ベースとなる組込み Linux* プラットフォームの定義は終了です。次は、仮想化を行うべきかどうかについて考えてみましょう。その後、Yocto Project* を例に、組込み開発環境向けの個々のツールについて説明します。

3. 仮想化

組込み分野で仮想化を行う主な理由は、重要なワークロードをソフトウェア・スタックのほかのワークロードから切り離し、専用のリソースを割り当てることです。ツールの定義と同様に、さまざまな選択肢があります。Linux* では、オープンソースの QEMU*、KVM*、Virtual Machine Manager ユーティリティーを組み合わせて、それをベースに保護された仮想ラッパーを作成することができます。

また、Oracle* VirtualBox* (https://www.virtualbox.org)、VMWare* (http://www.vmware.com)、Wind River* Hypervisor* (http://www.windriver.com/products/product-notes/PN_Hypervisor_0610.pdf) など、この分野の主要ソリューションも確認してみると良いでしょう。

仮想化を行うだけでは十分ではありません。仮想マシン・マネージャーやハイパーバイザーに専用のハードウェア・リソースを割り当てる必要があります。

4. 環境構築とソフトウェア設計

組込み Linux* OS と基本開発ツールセットを選択したら、ビルド環境の設定を行います。ここでは、Yocto Project* ベースのビルド・フレームワークと Yocto Project* の Poky Linux* ベースのアプリケーション開発ツールキット (ADT) を使用します。

図 4: Yocto Project* と ADT の構築フロー

以下は、ビルド環境の構築に必要な環境設定の例です。これらは、ADT に含まれる環境設定ファイルで事前定義されています。

export PATH=/home/users/poky/1.3/sysroots/x86_64-pokysdk-linux/usr/bin:/home/users/poky/1.3/sysroots/x86_64-pokysdk-linux/usr/bin/i586-poky-linux:$PATH
export PKG_CONFIG_SYSROOT_DIR=/home/users/poky/1.3/sysroots/i586-poky-linux
export PKG_CONFIG_PATH=/home/users/poky/1.3/sysroots/i586-poky-linux/usr/lib/pkgconfig
export CONFIG_SITE=/home/users/poky/1.3/site-config-i586-poky-linux
export CC=”i586-poky-linux-gcc -m32   -march=i586 –sysroot=/home/users/poky/1.3/sysroots/i586-poky-linux”
export CXX=”i586-poky-linux-g++ -m32   -march=i586 –sysroot=/home/users/poky/1.3/sysroots/i586-poky-linux”
export CPP=”i586-poky-linux-gcc -E -m32   -march=i586 –sysroot=/home/users/poky/1.3/sysroots/i586-poky-linux”
export AS=”i586-poky-linux-as “
export LD=”i586-poky-linux-ld   –sysroot=/home/users/poky/1.3/sysroots/i586-poky-linux”
export GDB=i586-poky-linux-gdb
export STRIP=i586-poky-linux-strip
export RANLIB=i586-poky-linux-ranlib
export OBJCOPY=i586-poky-linux-objcopy
export OBJDUMP=i586-poky-linux-objdump
export AR=i586-poky-linux-ar
export NM=i586-poky-linux-nm
export M4=m4

上記の設定から、クロスコンパイラーがビルドホストのデフォルトではなく、正しいライブラリーと binutils を選択するように強制する必要があることが分かります。

インテル® C++ コンパイラーと Yocto Project* ADT を併用する場合、これはさらに明白です。インテル® C++ コンパイラーと Yocto Project* ADT の組み合わせは、特にパフォーマンスに影響を与えやすいルーチンを最適化したり、アプリケーション全体を最適化するために使用されます。インテル® C++ コンパイラーは、–platform=yl13 オプションを指定して呼び出します。このシームレスな統合は、次に示すように、コンパイラー環境設定ファイルによって行われます。

*platform:
yocto

*yocto_sdk_toolchain:
%$(YOCTO_TOOLCHAIN)

*sysroot:
%$(YOCTO_SYSROOT)

*target_root:
%(sysroot)

*gcc_install:
%(sysroot)/usr/lib/gcc/i586-poky-linux/4.6.4

*intel_include:
%(intel_root)/../compiler/include

*intel_lib:
%(intel_root)/../compiler/lib/ia32

*exec_path:
%(yocto_sdk_toolchain)/i586-poky-linux

*exec_prefix:
i586-poky-linux-

*gxx_include:
%(sysroot)/usr/include/c++

*link_lib_path:
%(intel_lib)%(path_separator)%(gcc_install)%(path_separator)%(sysroot)/lib%(path_separator)%(sysroot)/usr/lib%(path_separator)%(sysroot)/usr/lib/i586-poky-linux/4.6.4

*link_start_files:
%{static?%{p?%(sysroot)/usr/lib/gcrt1.o;%(sysroot)/usr/lib/crt1.o};%{!shared?%(sysroot)/usr/lib/crt1.o}} %(sysroot)/usr/lib/crti.o %{static?%(sysroot)/usr/lib/i586-poky-linux/4.6.4/crtbeginT.o;%{shared?%(sysroot)/usr/lib/i586-poky-linux/4.6.4/crtbeginS.o;%(sysroot)/usr/lib/i586-poky-linux/4.6.4/crtbegin.o}}

*link_end_files:
%{!static?%{shared?%(sysroot)/usr/lib/i586-poky-linux/4.6.4/crtendS.o;%(sysroot)/usr/lib/i586-poky-linux/4.6.4/crtend.o};%(sysroot)/usr/lib/i586-poky-linux/4.6.4/crtend.o} %(sysroot)/usr/lib/crtn.o

*link_default_libs:
%{!static?%{i-dynamic|shared?-Bdynamic;-Bstatic}} -lsvml -limf \
%{!static?-Bdynamic} -lm \
%{!static?%{i-dynamic|shared?-Bdynamic;-Bstatic}} -lipgo -ldecimal \
%{!static?%{!no-intel-extensions?–as-needed -Bdynamic -lcilkrts -lpthread -lstdc++ –no-as-needed}} \
%{i_cxxlink?\
    %{cxxlib-gcc?\
      %{!static?%{i-static|static-libcxa?-Bstatic;-Bdynamic}} -lcxaguard}} \
%{openmp|parallel?%{!static?%{i-static?-Bstatic;-Bdynamic}} -liomp5} \
%{openmp-profile?%{!static?%{i-static?-Bstatic;-Bdynamic}} -liompprof5} \
%{openmp-stubs?%{!static?%{i-static?-Bstatic;-Bdynamic}} -liompstubs5} \
%{pthread|parallel|openmp|openmp-profile?%{!static?-Bdynamic} -lpthread} \
%{!static?%{i-dynamic|shared?-Bdynamic;-Bstatic}} %{pic-libirc?-lirc_pic;-lirc} \
%{!static?-Bdynamic} -lc \
%{cxxlib-gcc?\
    %{!cxxlib-nostd?%{!static?-Bdynamic} -lstdc++;%{!static?-Bdynamic} -lsupc++} \
    %{static|static-libgcc?\
      %{!static?-Bstatic} -lgcc -lgcc_eh; \
        %{!shared?%{!static?%{static-libgcc?-Bstatic;-Bdynamic}} -lgcc -lgcc_s}} \
    %{!static?-Bdynamic} -ldl -lc}

インテル® C++ コンパイラーは、すべてのリンクモデルに対して、このような正しいライブラリー、開始オブジェクト、終了オブジェクト、ヘッダーファイルなどの場所が事前定義された環境設定ファイルを提供します。この柔軟な環境設定ファイルにより、ほぼすべての GNU* クロスビルド環境でインテル® C++ コンパイラーを使用することができます。

インテル® C++ コンパイラーの Eclipse* 統合では、環境設定ファイルを簡単に編集できるようにエディターも提供しています。

図 5: インテル® C++ コンパイラーのクロスビルド環境設定ファイル用エディター

組込み開発のクロスビルド環境を設定する際、使用する信号処理ライブラリーの選択も重要です。VSIPL* とその派生ライブラリーは、この分野のオープンソース・ソリューションの準標準と言えるでしょう。インテル® IPP とインテル® MKL は、特に最新世代のインテル® アーキテクチャー向けの最適化など、いくつかの魅力的な機能を提供しています。

5. 消費電力のチューニング

消費電力のチューニングは、これまで組込みソフトウェア開発で最も軽視されてきた分野です。その最大の理由は、消費電力のチューニングはプラットフォーム・ハードウェア設計の領域と考えられていたためです。しかし、デバイスのバッテリー寿命をさらに延ばし、厳しい熱要件を満たすため、ソフトウェア・レベルで消費電力のチューニングを行う必要性が出てきました。

前述のとおり、利用可能なオープンソースのソリューションから見ていきましょう。Less Watts* イニシアチブ (http://www.lesswatts.org) は、OS およびアプリケーション・レベルで消費電力を削減する最も一般的な手法を提供しています。また、PowerTop*、Battery Life Toolkit*、Power QoS* など、さまざまなユーティリティーをダウンロードすることもできます。最適なアプローチを見つけるために一読されることをお勧めします。

MiserWare* の Granola* は、主にサーバー・アプリケーション向けの電力管理および電力フットプリントの統合ソリューションを提供しています。これらのソリューションは、組込みシステムにも適用できます。

最新のインテル® VTune™ Amplifier にも電力解析機能が追加されています。PowerTop* などのツールの持つ基本機能に加え、(周波数や電力モードが変わった場合) メモリー上のアプリケーションおよびシステム・ソフトウェアのソース位置にイベントを紐付ける機能を提供しています。(図 6)

図 6: ウェイクアップ・イベントとスリープモードの解析

6. パフォーマンス・チューニング

消費電力のチューニングに加えて、パフォーマンスのチューニングを行うことで、よく使われるアプリケーションを速く完了させ、OS が迅速に低消費電力ステートに移行できるようにすることは、小さなフォームファクターのデバイスのバッテリー寿命に大きく影響します。さらに、アプリケーションおよびソフトウェア・スタックには、円滑なユーザー・エクスペリエンス、あるいはすべてのワークを処理するハイパフォーマンスな組込みサーバー・プロセッサーの負荷を減らす専用の信号処理など、それぞれ達成すべきパフォーマンス目標があります。

Linux* で高度なパフォーマンス・チューニングに最もよく使用されているユーティリティーは、おそらく OProfile* でしょう。コマンドラインによるサンプリング機能と Eclipse* 統合開発環境 (IDE) への統合をサポートしています。

図 7: OProfile* とインテル® VTune™ Amplifier のパフォーマンス・データ収集

インテル® VTune™ Amplifier は、同様の基本機能と独自のグラフィカル・ユーザー・インターフェイス (GUI) を提供します。組込みアプリケーションのパフォーマンス解析および電力解析における主な機能は、リモートデータ収集と小さなフットプリントのリモート・サンプリング・コレクターです。また、多くの組込みアプリケーションは専用のマイクロエンジンやその他の I/O デバイスと連携するデバイスドライバーに大きく依存しているため、カーネル空間/ユーザー空間にわたってシステム全体のサンプリングを行えることも重要です。そのためには、プロセッサーのパフォーマンス・モニタリング・ユニット (PMU) ドライバーをカーネルモードで実装します。そうすることで、キャッシュミス、分岐予測ミス、メモリーの書き込み、TLB ルックアップなど、より多くのパフォーマンス関連のプラットフォーム・イベントにアクセスできます。さらに、ダイナミック・バイナリー・インストルメンテーション・ベースのソリューションではこれらのイベントを 1 つのアプリケーションからのみ見ることができますが、インテル® VTune™ Amplifier ではソフトウェア・スタック全体からも見ることができます。また、インテル® VTune™ Amplifier のパフォーマンス・サンプリングはメモリー利用を低く抑えています。これは、メモリー負荷の高いアプリケーション・ワークロードを持つ、多くの組込み使用ケースでスループットを最適化する際に重要です。

図 8 は、コマンドラインによるリモート・サンプリング・コレクターがターゲット上のドライバースタブと連携して、パフォーマンスと電力のリモート・サンプリングをどのように行うかを示しています。手動で結果ファイルを転送する必要はありません。

図 8: インテル® VTune™ Amplifier によるコマンドラインのリモートデータ収集

7. 信頼性とデバッグ

組込み分野以外では、完全なツールスイートの中でデバッガーは過小評価されがちです。組込みデバイスは現場で使用されることが多いため一般的な PC と比べると保守が困難であり、プラットフォーム・コンポーネントへの負荷も高くなりますが、一方でより高いソフトウェア・スタックの信頼性が求められます。つまり、組込みデバイスおよびインテリジェント・システム向けの開発ツールスイートには、優れたデバッグツールが欠かせません。

クロス開発の概要で触れたとおり、デバッガーにはアプリケーション・デバッガー、システムデバッガー、イベント・トレース・ツールの 3 種類があります。

アプリケーション・デバッグ

組込みクロス開発のアプリケーション・デバッグについては、GDB* を例に説明します。GDB* には、gdbserver と呼ばれるリモート・デバッグ・エージェントがあります。このデバッグ・エージェントをデバッグターゲットにインストールして、デバッグ対象を起動し、開発ホストからリモートでアタッチすることができます。

まず、ターゲットマシンで gdbserver を使ってプログラムを開始します。gdbserver は、エントリーポイントでプログラムの実行を自動で中断し、ホストデバッガーとの接続を待機します。次のコマンドは、アプリケーションを開始して、localhost のポート 2000 でホストデバッガーの接続を待機します。

     $ gdbserver localhost:2000 program
     Process program created; pid = 5685
     Listening on port 2000

gdbserver がリスニングを開始したら、ホストデバッガーにこの gdbserver との接続を確立するように指示し、ホスト上の GDB* でデバッグする場合と同様にデバッグセッションを開始します。

     $ gdb program
     (gdb) target remote targethost:4444
     Remote debugging using targethost:4444
     0x00007f29936d0af0 in ?? () from /lib64/ld-linux-x86-64.so.
     (gdb) b foo.adb:3
     Breakpoint 1 at 0x401f0c: file foo.adb, line 3.
     (gdb) continue
     Continuing.

     Breakpoint 1, foo () at foo.adb:4
     4       end foo;

すでに実行中のプログラムにアタッチすることもできます。その場合、ホストデバッガーと gdbserver 間の接続が確立されるまで対象プログラムの実行は中断されます。次のコマンドを使用します。

$ gdbserver localhost:2000 –attach 5685

このコマンドを実行すると、GDB* が実行中のプロセス ID 5685 にデバッグ接続するまで gdbserver は待機します。

仮想マシン上で実行中のアプリケーションをリモートでデバッグする場合、gdbserver デバッグ・エージェントでリモートデバッグするのと同じ要領で行います。

ただし、追加のステップとして、仮想マシン内から TCP/IP 通信が可能なことを確認し、仮想マシンの IP アドレスとデバッグ通信に使用するポートがネットワーク全体から見えるようにする必要があります。

QEMU* でこれを行う場合、bridge-utils パッケージがインストールされていなければいけません。ゲスト OS の仮想マシン内で、/etc/qemu-ifup ファイルに IP 転送の正しい設定を含めます。この設定については、Wikibooks* (http://en.wikibooks.org/wiki/QEMU/Networking) をご覧ください。

システム・ソフトウェア・デバッグ

システム・インテグレーターやデバイスメーカーにとって、ソフトウェア・スタックの信頼性と安定性を確保するため、デバイスドライバーやシステム・ソフトウェア・スタック・レイヤーへの取り組みは避けて通れないものです。

組込みインテリジェント・システムの分野では、ファームウェア、OS レベルのシステム、デバイスドライバーのデバッグに、JTAG インターフェイスを使用するのが最も一般的です。JTAG (Joint Test Action Group) IEEE 標準 1149.1 は、「プリント回路基板のテストに使用されるテスト・アクセス・ポート用の標準テスト・アクセス・ポートおよびバウンダリースキャン・アーキテクチャー」を定義しています。この標準規格は一般に、JTAG デバッグ・インターフェイスと呼ばれています。当初から、回路基板テスト用の標準規格として、OS に依存しない OS システムレベルのプラットフォーム・デバッグ用の標準インターフェイスとなるように開発されました。

JTAG の詳細情報と最新のシステム・ソフトウェア・スタックのデバッグにおける使用法は、「JTAG 101; IEEE 1149.x and Software Debug by Randy Johnson and Stewart Christie」 (http://download.intel.com/design/intarch/papers/321095.pdf) (英語) を参照してください。

OEM およびパートナーのアプリケーション/ドライバー開発者から見た場合、システムオンチップ (SoC) 統合インテリジェント・システムやスマートフォン・フォーム・ファクター・デバイスのさまざまな部分で実行するドライバー/ソフトウェア・スタック・コンポーネント間の相互作用を理解することは、プラットフォームの安定性を向上させる上で非常に重要です。シリコンの評価者から見た場合、低レベルのソフトウェア・スタックにより、プラットフォームが実際の利用状況で露呈するさまざまなストレス要素を示すテスト環境が提供されます。つまり、最近の SoC では、個々のハードウェア・コンポーネントのユニットテストにパスするだけでなく、パッケージ全体および複雑な実際の相互作用を理解する必要があります。このレベルの洞察を得るには、JTAG の詳細なハードウェア認識機能とターゲット上で実行している Android* OS のステート情報をエクスポートする機能を組み合わせた、JTAG ベースのシステム・ソフトウェア・デバッグ・アプローチを利用します。

特にデバイスドライバーのデバッグでは、チップセットの周辺機器の正確な状態と、デバイスドライバーと OS レイヤーおよび残りのソフトウェア・スタックとの相互作用の両方を理解することが重要です。

さまざまな JTAG ベンダーから組込みインテル® アーキテクチャー向けのシステム・デバッグ・ソリューションが提供されています。以下はその一例です。

American Arium* (http://www.arium.com)
Wind River* (http://www.windriver.com/products/JTAG-debugging/)
Macraigor Systems* (htttp://www.macraigor.com)
Green Hills Software* (http://www.ghs.com/products/probe.html)
Lauterbach* (http://www.lauterbach.com)

エージェント・ベースのデバッグでも、JTAG デバイス・インターフェイスを使用する場合でも、システムデバッガーは、OS 開発の主要な目的達成を支援する便利なツールです。デバッガーは、ブートプロセスの検証と、ランタイムエラー、セグメンテーション・フォルト、ブート中に正しく開始しないサービスなどの安定性問題の解析と修正に使用できます。ページテーブル、ディスクリプター・テーブル、命令トレースの詳細なアクセス情報を提供することにより、OS の構成に関する問題の特定と修正にも使用できます。命令トレースとメモリー・テーブル・アクセスの組み合わせは、スタック・オーバーフロー、メモリーリーク、データアボートなどの根本的な原因を特定できる非常に強力なツールとなります。

ブートプロセスの初期に JTAG デバッガーをターゲット・プラットフォームに接続する場合 (例えば、OS 起動時の問題を見つける場合など)、ハードウェア・ブレークポイントのみを使用するようにデバッガーを設定することが重要です。ターゲットメモリーの初期化が終わっていない時点でメモリーへのソフトウェア・ブレークポイントが書き込まれると、ブートプロセス全体がエラーになります。

start_kernel に到達するまでにデバッガーの実行コントロールをリリースすることで、Linux* の圧縮した zImage カーネルイメージがメモリーに展開された後にコードを解析することができます。これは、カーネルシンボル情報を含む vmlinux ファイルがロードされたことを意味します。この時点で、ソフトウェア・ブレークポイントを再度有効にできます。その後、アイドルループ mwait_idle に到達すると、オペレーティング・システムは正常にブートされます。

OS レベルのデバッグ向けの優れた JTAG デバッガー・ソリューションは、カーネルでエクスポートされるほかの情報とともに、カーネルスレッドとアクティブなカーネルモジュールの可視性を提供すべきです。動的にロードされるサービスとデバイスドライバーのデバッグを可能にするには、ドライバーの初期化と破棄のメモリー位置をエクスポートするカーネルパッチまたはカーネルモジュールを使用します。

特にシステム構成とデバイスドライバーのデバッグでは、デバイス構成レジスターに直接アクセスしてその内容を確認できることも重要です。これらのレジスターと内容は、レジスターに格納されている 16 進数でリストされるか、図 9 に示されているようにビットフィールドとして視覚化されます。ビット単位の仮想化を行うと、関連するデバイスドライバーが対話している間、デバッグ中のデバイスステートに対する変更をより簡単にキャッチして理解できます。

図 9: デバイスレジスターのビットフィールド表示

デバッグ・ソリューションで LBR (Last Branch Record) ベースの命令トレースへのアクセスが提供される場合、JTAG デバッガーの通常の実行制御機能とともにこの機能を使用して、例外での実行を停止し、実行フローを解析してランタイム問題の根本的な原因を探ることができます。

LBR は、ターゲットリセットからのコード実行をトレースするのに使用できます。コード実行の中断はこれらの MSR (Machine Status Register) に格納されるため、デバッガーは ‘To’ および ‘From’ アドレスを読み取って実行されたコードを再構築し、特定のメモリー範囲にアクセスして、コードを逆アセンブルすることができます。逆アセンブリーは、デバッガー・インターフェイスのトレース GUI に通常表示されます。割り込みにブレークポイントをセットすると、SMI (System Management Interrupt) やほかの例外の前に実行されたコードを調べるときに役立ちます。

イベントトレースのデバッグ

SoC で多数のソフトウェア・コンポーネントとハードウェア・コンポーネントが相互に作用する場合、デバッグ中の問題の原因は増加します。異なるソフトウェア・コンポーネント間の相互作用は、多くの場合タイミング・センシティブです。コンポーネント間で多くの相互作用があるコードベースをデバッグする際、1 つの特定のコンポーネントをシングルステップで処理することは、現実的ではありません。デバッグそのものによりタイミング動作に影響を及ぼし、さらに悪い問題 (ハイゼンバグ) を引き起こす可能性があるため、従来の printf デバッグもこのコンテキストでは有効ではありません。

この問題への対応を支援する、さまざまなスタティック・ソフトウェア・インストルメンテーション・ベースのデータ・イベント・トレース技術があります。共通なのは、少量の DRAM バッファーメモリーを利用してイベントデータをキャプチャーし、ロギング・メカニズムを使用してトレース結果をログファイルに書き込む点です。データ・トレース・モニタリングは、トレースロギング API を直接処理することでリアルタイムに、またはより複雑なソフトウェア・スタック・コンポーネントの相互作用を解析するトレースビューアーによりオフラインで行うことができます。

この種の実装では、SVEN、LTTng*、F-Trace* の 3 つが最も一般的です。

LTTng* Project: https://lttng.org/
Ftrace*: http://elinux.org/Ftrace
SVEN*: http://software.intel.com/en-us/intel-system-studio

8. まとめ

複雑な SoC のLinux* システム・ソフトウェア・スタックの開発には、特有な課題がいくつかあります。しかし、適切なソフトウェア開発ツールと開発環境を利用することで、これらの課題に簡単に対処することができます。インテル® アーキテクチャー・ベースの組込みシステム向けソフトウェア開発は容易で、多くの場合、ほかのアーキテクチャーよりも幅広い選択肢があります。ほかの組込みアーキテクチャーで利用されている一般的な開発手法は、インテル® アーキテクチャーにも適用できます。組込み分野、特に組込み Linux* ターゲットの場合、豊富な開発ツール・エコシステムがすでに確立されています。Yocto Project* や OpenEmbedded* などのオープンソース・プロジェクトは、豊富なフレームワークとユーティリティーを提供しています。そして、これらは Mentor Graphics*、Wind River*、Green Hills* Software などの商用ソリューションによって拡張されています。組込みアーキテクチャーは、長年にわたって組込み分野で使用されてきた実績があります。開発ホストとターゲットで同じ基本組込みアーキテクチャーを使用する利点は、クロス開発の必要性がなくなることです。ただし、システム開発では、多くの場合まだクロス開発が推奨されます。

クロス開発が不要な場合であっても、クリーンなビルドおよび検証環境を確保するため、クロス開発を行ったほうが良いことも多々あります。Linux* では、インテル® アーキテクチャー向けのカスタマイズ可能な幅広いビルド・ソリューションを目的に合わせて利用できます。

オープンソース・コミュニティー、各種ツールベンダー、そしてインテルから豊富なソフトウェア開発ツールが提供されているため、特に PC 中心のネイティブ開発からインテリジェント・システムの開発へ初めて移行する場合、開発をより容易に行えるでしょう。

この記事では、組込み Linux* 開発のさまざまな課題と各種開発ツールについて説明しました。また、インテル® アーキテクチャー向けの開発において、解析およびデバッグ機能を利用する重要性を述べました。

インテル® アーキテクチャー向けの開発を成功に導く鍵は、充実したエコシステムを利用し、ニーズに合ったビルド環境を定義することです。ターゲット環境への依存性を取り除き、シンプルなビルド環境を構築することが重要です。printf で重大な問題をデバッグすると多大な時間がかかります。高度なクロスデバッガーとパフォーマンス解析ツールを活用することで、ソフトウェア・スタックの安定性とパフォーマンスを高められます。カスタム Linux* ソフトウェア環境を定義する際は、最初に Yocto Project* などのインテル® アーキテクチャー向け組込み Linux* フレームワークを調査すると良いでしょう。

インテルは、組込みおよびインテリジェント・システム向けの統合ソフトウェア開発ソリューションを提供するべく、積極的に取り組んでいます。

この記事では、組込み開発プロジェクトに取り掛かる上で考慮すべき点を示しました。より詳しい情報については、「関連情報」の資料をご覧ください。