i.MXの開発環境を構築してみた
(Yocto編) |
技術コラム では Yocto Project を使ってi.MXのBSPをビルドしました。
ビルドが終わったところで、ビルドツールである bitbake が作成したディレクトリを見ていこうと思います。
どのようなディレクトリが作られたのかを知っておくと開発の効率が上がり、トラブルシュートにも役立ちます。
この記事では、i.MX BSPをビルドした環境を例に、よく使うディレクトリを整理して紹介します。 たくさんのディレクトリがありますが、私が開発中によくアクセスするディレクトリに絞って説明します。
紹介するディレクトリはこちらです。なお、ディレクトリの場所はconf/local.confでディレクトリの場所を変更していないものとします。
以下、適宜Yocto Project Reference Manualの4 Source Directory Structureを引用します。
また、以降の内容はi.MX 95
Verdin 評価キット向けにNXPのBSP(L6.12.3_1.0.0)を使ってイメージimx-image-fullをビルドした環境で確認しています。
${BBPATH}/tmp
${BBPATH}はbitbakeを有効にする際に定義される環境変数で、以下のコマンドを実行した時に渡したビルドディレクトリ(以下コマンドの<build/directory>)を指しています。
$ source setup-environment
... (出力は省略)
$ echo ${BBPATH}
=> <build/directory> が出力される
本記事では出力でビルドディレクトリが表示される部分を ${BBPATH} で置き換えています。実際の出力ではパスが表示されますので適宜読み替えてください。
前置きを終えたのでtmpについての話を始めます。bitbakeでlinuxイメージをビルドすると${BBPATH}の直下にtmpというディレクトリができます。
tmpは「temporary=一時的」から来ています。Yocto ProjectのReference Manualから関連する箇所を引用します。
Note
By default, the Build Directory contains TMPDIR, which is a temporary directory the build system uses for its work.
個人的な解釈になりますが、temporaryの心は「このディレクトリ内のディレクトリやファイルはbitbakeによって削除されます」だと考えています。
「gitで管理しているから大丈夫」
ではありません。 bitbakeのサブコマンドやオプションによってはgitの管理ディレクトリごと削除されます。原則としてtmpディレクトリ以下で開発しないことです。
それではさらに下の階層へ進みます。
work
ビルドに必要なソースコードや中間ファイルがレシピ別に保存されます。 タスク実行時のログも保存されているので、ビルドでエラーが発生した時はこのディレクトリへ潜って原因を探します。
workディレクトリ以下には複数のディレクトリが作成されています。今回の環境では以下が作成されていました。
- all-poky-linux
- armv8a-mx95-poky-linux
- armv8a-poky-linux
- imx95_19x19_lpddr5_evk-poky-linux
- imx95_19x19_verdin-poky-linux
- recipetool-o3wixn8f
- x86_64-linux
これらは各レシピの中でMULTIMACH_TARGET_SYSという変数で指定されるディレクトリです。このように分けられている理由は、異なるターゲット向けのイメージを同じビルドディレクトリでビルドした際に、ビルド結果を共有できるレシピとできないレシピに分類するためです。
work-shared
いくつかの特殊なレシピで使用されます。 今回の条件でビルドした場合は以下のディレクトリが作成されました。
- gcc
- llvm
- linux kernel
このディレクトリは効率的なビルドのために用意されるもので、以下のような条件を満たすレシピで使用されているようです。
- ソースコードのサイズが大きい
- いくつかのレシピで同じソースコードが使用される
4.2.8.12 build/tmp/work-shared/
For efficiency, the OpenEmbedded build system creates and uses this directory to hold recipes that share a work directory with other recipes.
"For efficiency" = 「効率化のため」とあることが確認できます。
deploy
ビルドの最終成果物が保存されます。成果物はいくつかあり、それぞれにディレクトリが用意されます。
下位のディレクトリを見ていきましょう。
images
Linuxイメージの保存場所です。Linuxイメージの他、デバイスツリーファイルやブートローダーも保存されます。
deb
i.MXのBSPはデフォルトではconf/local.confに以下の設定があるため、レシピの成果物を .deb パッケージへまとめます。
# Switch to Debian packaging and include package-management in the image
PACKAGE_CLASSES = "package_deb"
各レシピで作成された .deb ファイルがここに保存されます。
まとめ
今回はbitbakeが作成したビルドディレクトリの中から開発中に参照することが多いディレクトリを紹介しました。
スムーズにビルドできるのであればこれらを参照することはないのですが、なかなか現実はそうもいかないものです。 bitbakeはビルドの中間生成物やログをルールに従って作成したディレクトリに格納しているので、ディレクトリの構造を把握しておくとログや作業ディレクトリに素早く到達することができます。
ネクスティ エレクトロニクスの開発部隊ではNXP社のi.MXシリーズを活用した製品開発の提案やサポートを行っています。
最新のi.MX9シリーズも使用していますので、お気軽にお問い合わせください。
おまけ
deployディレクトリに保存されたLinuxイメージ以外のファイルについて軽く紹介します。
マニュフェストファイル
.manifest
という拡張子を持つファイルです。このファイルにはイメージに含まれるパッケージがリストアップされています。ビルドしたイメージに想定したレシピが含まれているかを書き込む前に確認できます。
SDKにもマニュフェストファイルが作成されます。今回はSDKの話をしていないので蛇足でした、はい。
ビルドしたdebファイルをaptサーバで発信する
この内容は bitbakeで作成したパッケージをapt(ただしデバッグ用途に限る)
を ほぼなぞって 大変参考にしています。
例えば以下のような状況では、ビルドしたイメージに後からライブラリやツールを追加したいことがあります。
- 機能を調べたいだけのアプリがあり、イメージを焼き直すほどの変更量ではない
- デバッグ目的で一時的に開発向けパッケージを追加したい
- いつも使っているソフトウェアを実機でも使用したい
このような時、debディレクトリ内にあるファイルを実機に転送し、
dpkgやaptでインストールするという方法があります。ただし、この方法では依存するパッケージを全て見つけて手作業で実機に転送する必要があります。これはなかなか骨が折れます。
そこで、ビルドPCにaptサーバを立て、このサーバでdebディレクトリに格納されたdebパッケージを配布するすることで、実機からこのaptコマンドでパッケージの追加や更新を行えるようにします。
手順は以下の通りです。
-
・ ビルドPC
- 1.
aptインデックスの作成 - 2.
aptサーバの立ち上げ
- 1.
-
・ 実機
- 1.接続先
aptサーバの設定 - 2.時刻設定
- 3.
aptコマンドの実行
- 1.接続先
ビルドPC - 1. aptインデックスの作成
bitbakeが提供するレシピを使う場合は、
$ bitbake vim # 追加したいパッケージが `IMAGE_INSTALL`にない場合はビルドしておきます
$ bitbake package-index
dpkg-scanpackages(aptが提供するコマンド)を使う場合は、
$ sudo apt install dpkg-dev
$ cd ${BBPATH}/tmp/deploy/deb
$ dpkg-scanpackages . /dev/null | gzip -9c > Packages.gz
どちらもほぼ同じ結果になります。 bitbakeを使う方が楽だと思います。
ビルドPC - 2. aptサーバの立ち上げ
httpサーバを立ち上げます。Pythonを使う方法が楽だと思います。
$ sudo apt install python3
$ cd ${BBPATH}/deploy/
$ python3 -m http.server 8000
実機 - 1. 接続先aptサーバの設定
aptサーバに接続するために /etc/apt/sources.listファイル あるいは /etc/apt/sources.list.d/
ディレクトリ以下にファイルを作る必要があります。
中身は以下の通りです。 <server address> はビルドPCのIPアドレスやURLを設定してください。
bitbake package-indexでインデックスを作成した場合
deb [trusted=yes] http://<server address>:8000/deb/all ./
deb [trusted=yes] http://<server address>:8000/deb/cortexa55 ./
deb [trusted=yes] http://<server address>:8000/deb/cortexa55-mx95 ./
deb [trusted=yes] http://<server address>:8000/deb/toradex_smarc_imx95 ./
dpkg-scanpackages でインデックスを作成した場合deb [trusted=yes] http://<server address>:8000/deb ./
証明書周りを省略しているため、[trusted=yes] を付けてaptに対して信用するよう強制しています。
上記のファイルはbitbakeで作成し、イメージに追加させることもできます。 Yoctoのドキュメントを参照すると、28.4.1 Build Considerations以下のように手順や説明されています。
You can use the PACKAGE_FEED_ARCHS, PACKAGE_FEED_BASE_PATHS, and PACKAGE_FEED_URIS variables to pre-configure target images to use a package feed. If you do not define these variables, then manual steps as described in the subsequent sections are necessary to configure the target. You should set these variables before building the image in order to produce a correctly configured image.
PACKAGE_FEED_ARCHS, PACKAGE_FEED_BASE_PATHS, PACKAGE_FEED_URIS
を設定することでレポジトリにアクセスするための設定ファイルが自動的に作成され、イメージに追加されます。aptの場合は以下のようになります。
PACKAGE_FEED_URIS = "https://<server address>:8000"
PACKAGE_FEED_BASE_PATHS = "deb"
PACKAGE_FEED_ARCHSを設定しない場合、実機向けにビルドした全てのファイルを対象にする設定ファイルを作成します。
実機 - 2. 時刻設定
apt update が正常に機能するためにはサーバと実機の時刻が概ね一致している必要があります。
実験中は半日くらいのずれであれば更新されましたが時刻が一致しているに越したことはないです。
手段はいくつかありますが、最も簡単な方法は date コマンドを使う方法だと思います。
- ビルドPCで以下を実行
# date -u +%m%d%H%M%Y.%S
- このコマンドの出力結果をコピーします
- 実機で以下を実行
# date -u <2.でコピーした結果を貼り付け>
# date #日付が設定されていることを確認
実機 -3.
aptコマンドの実行
これでビルドPCでビルドしたパッケージを実機からaptコマンドで取得できるようになります。
実機とビルドPCがEthernetで接続されていることを確認し、aptを実行します。
# apt update
(出力省略)
# apt info vim
vim/unknown 9.1.1652-r0 arm64
# apt install vim
(以下略)
関連情報と参考資料
お問い合わせ
関連技術コラム
関連製品情報

ネクスティ エレクトロニクス制作 NXP車載マイコンS32K311評価ボード
S32K311は、小パッケージで高性能、最新機能を安価に利用できるNXPの最新車載マイコンです。特徴と、当社制作のS32K評価ボードを紹介します。
- NXP Semiconductors N.V.
- NEXT Mobility

NXPの車載CAN/LINトランシーバー製品の特徴を徹底解説
車載ネットワーク製品をお探しのECU開発メーカー様向けに、車載環境の厳しい条件に耐えることのできる、NXPの車載CAN/LINトランシーバー製品の特徴について解説します。
- NXP Semiconductors N.V.
- NEXT Mobility
- ICT・インダストリアル

NXPの車載汎用マイコン製品の紹介
NXPの車載汎用マイコンは、S32K1、S12 MagniV、S32K3ファミリーをラインナップし、高性能、セキュリティ、コスト効率を兼ね備え自動車技術の進化を支えます。
- NXP Semiconductors N.V.
- NEXT Mobility

NXPのNPUを搭載したi.MX/MCXによるエッジAIソリューションをご紹介
利用が急増しているエッジAIについて、実際の機器を踏まえて解説します。NXPがリリースしている、NPUを搭載したプロセッサー、マイコンをご紹介します。
- NXP Semiconductors N.V.
- NEXT Mobility
- ICT・インダストリアル
- スマートファクトリー・ロボティクス

NXPの車載マイコンS32K1の魅力を徹底解説
NXPの車載マイコンS32K1シリーズは、ARM Cortex-M0+およびM4Fコアを搭載し、高い処理能力と低消費電力を実現します。その魅力と特徴を徹底解説します。
- NXP Semiconductors N.V.
- NEXT Mobility

NXPの車載ミリ波レーダー製品の紹介
先進運転支援システム(ADAS)において重要なセンサー車載ミリ波レーダーの概要と、その市場をリードするNXPの先進的なレーダー製品ファミリーをご紹介します。
- NXP Semiconductors N.V.
- NEXT Mobility
- ICT・インダストリアル
- スマートファクトリー・ロボティクス





