ブログ:
Toradex Yocto Project Linux OS カスタムマニュアル

2020年10月28日水曜日
Linux
このブログ記事が廃れたです。BSP 5用のご参考ください

Linux

本マニュアルについて

本マニュアルではOpen Embedded (Yocto Project) の使い方やレシピの読み方、トラデックスのCPUボードに搭載すrootfsやLinux OS,ブートローダーなどをカスタマイズする手順を記述しています。

参考:

本マニュアルのPDFダウンロード


1.実行環境

本マニュアルの実行環境は下記です。

仮想化ソフト:VMWARE Player v15.5.6
Host OS: Windows 10 1909
Guest OS: Ubuntu Desktop 18.04LTS 64bit(英語版)
BSP:v3.0.4
CPUモジュール:Colibri-iMX7D 512MB V1.1C
キャリアボード:Colibri 評価ボードRev 3.2 A+ アクセサリーキット+EDT 7.0 TFT WVGA(LCD)

2.事前準備

本マニュアルはLinux OSイメージ開発マニュアルの内容をすべて終えた状態で進めています。

3.前提知識

Linux OSイメージ開発マニュアルの内容をご理解いただいた状態を前提としています。

4.注意点

オープンソース系を利用した開発に共通することですがOpen Embedded (Yocto Project)をすべてを理解しようとするときりがなく開発効率を損ないます。必要なタイミングで必要な知識を身につけるというスタンスで理解することを推奨いたします。本マニュアルで扱うことはOpen Embedded (Yocto Project)による開発でよく使う内容に絞っています。

開発環境と実行環境の違いをわかりやすくするためにコマンドの表記の前に下記をつけています。
開発環境(PC)上で入力するコマンド:[ubuntu]$
実行環境(モジュール)上で入力するコマンド(Linux):[colibri-imx7]#
実行環境(モジュール)上で入力するコマンド(U-Boot):[uboot]#

コピーについて
本マニュアル内のコマンドなどをコピーした場合、改行が入ったり「-」が抜けてしまうことがあるのでご注意ください。一度テキストエディタなどに張り付けてコピーした内容をご確認ください。

Open Embeddedの大雑把な仕組み

Open Embeddedはbitbakeというコマンドを実行することでOSイメージやミドルウェアなどをビルドしRootFSやKernel、ブートローダーなどを作成するビルドシステムです。Open Embedded自体はPythonで作成されています。
bitbakeのビルド処理は大雑把に下記のような手順が実行されます。

do_fetch: ソースコードをダウンロード
do_unpack: ソースコードを解凍(展開)
do_patch: パッチを適用
do_populate_lic: ライセンスファイルのコピー
do_prepare_recipe_sysroot: makeに必要なツールの準備
do_configure: configureを実行
do_compile: makeを実行
do_install: make install を実行
do_package: パッケージをサブセットに分離など
do_populate_sysroot: sysroot にインストール
do_packagedata: パッケージデータの移動
do_package_qa: パッケージのチェック処理
do_package_write_ipk: パッケージの作成(ipk)
do_rm_work:一時ファイルの削除

最もシンプルなbitbakeの使用コマンドは下記のようにbitbakeするターゲット名を指定するだけです。
bitabke <ターゲット名(レシピ名)>

このコマンドを行うだけでソースコードのダウンロードからパッチ適用、makeなどを行いRootFSやカーネルがすべて自動で出力されます。このビルドターゲットがどのようなビルドの内容なのかという定義を「レシピ」といわれるファイルで定義します。
レシピにはソースコードのダウンロードURIやパッチファイルの指定、各工程前後のシェルスクリプトの実行などを定義します。
レシピにはソースコードなどからひとつの生成物を作成するものとソースコードはなく複数のレシピのみで構成されるものがあります。例えばミドルウェアなどは前者であり、OSイメージなどは元のソースコードがあるわけではなくミドルウェアやカーネルの組 み合わせでしかないため後者になります。レシピの書き方はシェルに似ていますが独自定義などもありよく使用する定義値などは覚える必要があります。Open EmbeddedはRootFSやKernelなどの最終的な出力物以外にもターゲット向けコンパイラやaut oconf、unzipなど出力物を生成するために必要なツール類も自動で出力します。

ベースのOSイメージのレシピを選択

トラデックスが用意したOSイメージのレシピは/work/oe-core/layers/meta-toradex-demos/recipes-images/images/配下にあります。BSP3.0.4においてはconsole-tdx-image.bbのみ対応しています。ほかにもファイルは存在しますがサポートはしていません。
下記のようにbitbakeコマンドでOSイメージを作成することができます。

[ubuntu]$ bitbake console-tdx-image

bitbakeの一部のコマンドだけを実行

下記コマンドでbitbakeの一部の処理だけを実行できます。

[ubuntu]$ bitbake <レシピ名> -c <処理名>

例えば下記のように入力することでカーネルのソースコードのダウンロードだけを行うことができます。

[ubuntu]$ bitbake virtual/kernel -c fetch

本コマンドではbitbakeで実行される一連の処理以外にも存在する処理を実行可能です。
各レシピが持つ処理一覧は

[ubuntu]$ bitbake <レシピ名> -c listtasks で表示可能です。

レシピ内の演算子

レシピ内ではいくつかの演算子があります。意味は下記のようになっています。

= 通常の設定
?= 未定義の場合に設定
??= ?=よりさらに弱い設定
:= 即時代入
+= 後ろへ追加挿入(スペースあり)
=+ 前へ追加挿入(スペースあり)
.= 後ろへ追加挿入(スペースなし)
=. 前へ追加挿入(スペースなし)
_append 解析後後ろへ追加挿入(スペースなし)
_prepend 解析後前へ追加挿入(スペースなし)

レシピ内の定義の読み方

下記はよく使用する定義です。

SRC_URI:ソースコードやパッチなどの入手先
SRCBRANCH:ブランチ名
SRCREV:コミット番号
IMAGE_INSTALL:インストールを行うパッケージ
PV:バージョン
PR:リビジョン
DEPENDS:ビルド時に依存するパッケージ
RDEPENDS:実行時に依存するパッケージ
COMPATIBLE_MACHINE:互換性のあるターゲット
<定義>_append_<ターゲット名>:該当ターゲット時のみ適用される定義
MACHINE:ターゲット名
S:ソースディレクトリ
B:ビルドディレクトリ
D:インストール先ディレクトリ

DISTRO_FEATURES:ディストリビューションに対しての機能性を定義します。
各レシピ内でこの定義に含まれるものを参照してビルドを行います。
例えばDISTRO_FEATURESにx11が含まれていればx11に関連するコンパイルオプションや設定が取り込まれます。
x11を使用しない場合はDISTRO_FEATUREからx11を取り除くことでその分OSイメージが小さくなります。

MACHINE_FEATURES:サポートするハードウェアを定義します。
各レシピ内でこの定義に含まれるものを参照してビルドを行います。
例えばMACHINE_FEATURESにbluetooth が含まれていればbluetoothに関連する機能や設定が取り込まれます。
bluetoothを使用しない場合はMACHINE_FEATURESからbluetoothを取り除くことでその分OSイメージが小さくなります。

レシピ内の処理の読み方

レシピ内の処理には下記のようなdo_<処理名>に対してそれぞれ事前処理、処理の上書きが存在します。

do_fetch: ソースコードをダウンロード
do_unpack: ソースコードを解凍(展開)
do_patch: パッチを適用
do_configure: configureを実行
do_compile: makeを実行
do_install: make install を実行
do_populate_sysroot: sysroot にインストール
do_package: パッケージ化用のディレクトリにインストール
do_package_write: パッケージの作成(ipk, deb, rpm)
do_build: ビルド終了用のタスク
do_rm_work:一時ファイルの削除

例えばdo_configure_prependという処理を記述すればconfigureの以前処理を行うスクリプトを記述します。
do_installという処理を記述すればinstallの処理を上書きします。

自作タスクの登録
addtaskで自作したタスクの登録が可能です。
addtask <新規に定期したタスク名> after <タスク名> before <タスク名>

例えば下記の記述はunpackとpatchの間でhelloを出力するタスクを登録しています。

do_echo () {
		echo "hello"
		}
addtask do_echo after do_unpack before do_patch

レシピの実行ログと結果のログ

bitbakeを実行後どのような処理が実行されたのか下記に実行コマンドのログが出力されます。

/work/oe-core/build/tmp/work/<アーキテクチャ名>/<レシピ名>/<バージョン>/temp/run.do_<処理名>

例えばcolibri-iMX7のカーネルのconfigureのログの場合下記のようになります。

/work/oe-core/build/tmp/work/colibri_imx7-tdx-linux-gnueabi/linux-toradex/4.14-2.3.x+gitAUTOINC+baa6c24240-r0/temp/run.do_configure

同ディレクトリにlog.do_<処理名>というファイル名で実行結果のログが出力されます。

例えばcolibri-iMX7のカーネルのcompileのログの場合下記のようになります。

/work/oe-core/build/tmp/work/colibri_imx7-tdx-linux-gnueabi/linux-toradex/4.14-2.3.x+gitAUTOINC+baa6c24240-r0/temp/log.do_compile

log.task_orderに実行したタスクのオーダーと各タスクに対するログのファイル名が出力されます。

レシピの追加/削除

例えばwebサーバやPythonを必要とするOS イメージを開発する場合、コンソールイメージのレシピ(console-tdx-image.bb)をベースとして下記のようにレシピ内のIMAGE_INSTALLに項目を追加しwebサーバの機能(lighttpd)やPythonを追加します。

IMAGE_INSTALL += " ¥
	packagegroup-boot ¥
	packagegroup-basic ¥
	udev-extra-rules ¥
	${CONMANPKGS} ¥
	${ROOTFS_PKGMANAGE_PKGS} ¥
	timestamp-service ¥
	${@bb.utils.contains('DISTRO_FEATURES', 'wayland', ¥
		'weston weston-init wayland-terminal-launch', '', d)} ¥
	${@bb.utils.contains('DISTRO_FEATURES', 'x11 wayland', ¥
		'weston-xwayland xterm', ¥
	bb.utils.contains('DISTRO_FEATURES', 'x11', ¥
		'x-window-xterm', '', d), d)} ¥
	python3 ¥
	python3-modules ¥
	lighttpd ¥
"

変更後、bitbakeを行うとPythonとwebサーバ機能(lighttpd)が追加されたコンソールイメージが作成されます。
出力されたOSイメージを書き込み、動作させることでこれらの機能が追加されたことが確認できます。
逆に不要なものがあればレシピを削除することで機能を削除することができます。

local.confに追加することも可能です。こちらのほうがもともとのレシピを変更せずに対応可能です。
(pythonの手前はスペースが必要です。)

IMAGE_INSTALL_append = " python3 python3-modules lighttpd"

削除する場合は下記のような記述をします。${CONMANPKGS} を削除する例

IMAGE_INSTALL_remove = " ${CONMANPKGS} "

存在するレシピの確認

OSイメージのレシピに機能を追加するにはどのような機能が存在するかを把握しておく必要があります。
下記のように入力するとBSP内(レシピ全体)に含まれるパッケージとバージョンを表示できます。

[ubuntu]$ bitbake -s



機能ごとに分割されたレシピの追加

OSイメージのレシピに機能を追加するにはどのような機能が存在するかを把握しておく必要があります。
下記のように入力するとBSP内(レシピ全体)に含まれるパッケージとバージョンを表示できます。

[ubuntu]$ bitbake -s

例えばpythonを追加する場合、pythonの機能ごとにレシピが分かれていてレシピにpythonだけを追加してもpythonのすべての機能を使用することはできません。機能ごとにレシピが分割されています。消費するリソースを最小限にできるように必要な機能だけをレシピに組み込めるようになっています。

下記コマンドでpython(3系)のレシピ一覧を表示できます。

bitbake -s | grep ^python3-



出力ファイルの追加

レシピから出力されるファイルはレシピを組み込んだだけではすべてのファイルが組み込まれるとは限りません。一部のファイルはレシピ以外にもファイルの出力を指定しないといけないものがあります。

例えば下記のdhcpのレシピはlocal.confなどにdhcpを指定しても何も出力されません。
/work/oe-core/layers/openembedded-core/meta/recipes-connectivity/dhcp/dhcp_4.4.1.bb

レシピ名を指定した場合に出力されるファイルはFILES_${PN}になりますがdhcp.incを見ると何も指定されていないことがわかります。

FILES_${PN} = "“

その代わりFILES_${PN}-serverやFILES_${PN}-client、FILES_${PN}-server-configなどが存在します。
dhcpサーバーの機能がほしい場合dhcp-server、クライアントの場合dhcp-client、サーバーの設定ファイルの場合、dhcp-server-configを指定すれば該当機能の出力ファイルがイメージに追加されます。

コンパイルオプションの変更

レシピにはコンパイルオプションがあるものがあります。デフォルトのコンパイルオプションから変更したい場合はlocal.confに下記のように記述します。

PACKAGECONFIG_append_pn-<レシピ名> = “<コンパイルオプション>“

例えばlighttpdにopensslのコンパイルオプションをつけたい場合は下記のように記述します。

PACKAGECONFIG_append_pn-lighttpd = "openssl “

lighttpdのレシピ内にPACKAGECONFIGの記述があります。
/work/oe-core/layers/openembedded-core/meta/recipes-extended/lighttpd/lighttpd_1.4.51.bb

PACKAGECONFIG[openssl] = "--with-openssl,--without-openssl,openssl"

上記の記述の意味は下記です。
PACKAGECONFIG[p0] = “p1,p2,p3,p4”
p0の指定があればp1をコンパイルオプションに適用
p0 の指定がなければp2をコンパイルオプションに適用
p0 の指定があればp3をDEPENDSに追加
p0 の指定があればp4をRDEPENDSに追加(上記の場合p4は省略されています。)

各レシピがどのようなコンパイルオプションがあるかはレシピの内容を見る必要があります。
レシピが扱うミドルウェアが持つレシピ内にはないコンパイルオプションを記述したい場合はレシピを変更する必要があります。

依存関係の確認

bitbake -g <レシピ名>で依存関係情報を出力できます。
例えばconsole-tdx-imageの依存関係情報を出力するには下記のコマンドになります。

[ubuntu]$ bitbake -g console-tdx-image

コマンドを実行すると下記3つのファイルが出力されます。
pn-buildlist :指定レシピに含まれるレシピ一覧
task-depends.dot :各タスクの依存関係一覧
recipe-depends.dot :各レシピの依存関係一覧

環境情報の確認

bitbake -e <レシピ名>で環境情報を出力できます。レシピ名がない場合はグローバルの環境情報を出力します。
例えばconsole-tdx-imageの環境情報を出力するには下記のコマンドになります。

[ubuntu]$ bitbake -e console-tdx-image > log

この情報を見ると内部でDISTRO_FEATURESやMACHINE_FEATURES、IMAGE_INSTALL、RDEPENDSなどにどんな値が設定されているかを確認することができます。

仮想レシピ名

いくつかの仮想レシピ名が存在します。
これらは実体のレシピ名を知らなくても使える便利なものです。

virtual/kernel
linuxカーネル本体を示す名前実体はlinux-toradex

virtual/bootloader
ブートローダーを示す名前実体はu-boot-toradex

レシピのファイルの所在を調べる

カーネルのレシピ名はすべてのモジュール共通でlinux-toradexです。このレシピのファイルがどこに存在するかを下記コマンドで検索するといくつか候補が出てきますがどれに当たるのかはわかりません。(モジュールごとに同名レシピが存在します。)

[ubuntu]$ find /work/oe-core/layer/ -name linux-toradex*

確実にファイル名を知るには下記のコマンドで確認することができます。

[ubuntu]$ bitbake -c checkuri linux-toradex > log

ログの最後のほうにlinux-toradex_XXX.bbというファイル名が出力されているのがレシピのファイル名です。



レシピのダウンロードファイルを調べる

bitbakeでダウンロードしたものはデフォルト設定ではoe-core/build/downloadsに格納されます。
レシピのSRC_URIがhttpやftpの場合ファイルで保存されるためファイル名でわかります。
gitでダウンロードした場合はgitのディレクトリが作成されます。どこに保存されるかを調べるにはgitのURLからわかります。
例えば下記のLinuxカーネルのレシピの場合
/work/oe-core/build/../layers/meta-toradex-nxp/recipes-kernel/linux/linux-toradex_4.14-2.3.x.bb
SRC_URIはgit://git.toradex.com/linux-toradex.git;protocol=git;branch=${SRCBRANCH} になっています。
git://以下の部分を抽出し/は.に置き換えられてダウンロードしたディレクトリはgit.toradex.com.linux-toradex.gitという名前になります。

下記のようなコマンドを入力すると所在がわかります。
find /work/oe-core/downloads/ -type d | grep git.toradex.com.linux-toradex.git
下記の場合、/work/oe-core/downloads/git2/git.toradex.com.linux-toradex.git/がgitのディレクトリになります。



クリーン

一部レシピやパッチを作成してソースコードを変更した場合にはクリーンしないとビルドしてくれません。
例えばkernelを変更した場合はコマンド実行しクリーンしてからビルドを行います。

bitbake -c cleansstate virtual/kernel && bitbake virtual/kernel

何かおかしくなってすべてをビルドしなおしたい場合はすべてをクリーンする必要がありますが非常に手間がかかります。
その場合はbitbakeで出力されたファイルやディレクトリをすべて削除してから再度bitbakeを行います。
対象は下記です。ダウンロードしたソースコードとconfディレクトリだけはそのまま残します。
oe-core/sstate-cache
oe-core/build/deploy
oe-core/build/buildhistory
oe-core/build/cache
oe-core/build/tmp

RootFSのカスタマイズ

アプリケーションを格納して自動実行する設定を加えるなどrootfsの中身を変更したい場合はOS作成して出力されたOSイメージのrootfsを解凍して修正後、再度圧縮してください。下記の例はOS起動後、時刻のログを出力するアプリケーション(シェル)を自動実行するように修正します。

rootfs修正用ディレクトリ作成

[ubuntu]$ cd /work/image
[ubuntu]$ sudo mkdir rootfs

[ubuntu]$ cd rootfs

rootfs解凍

[ubuntu]$ sudo tar -xvf ../Colibri-iMX7_Console-Image-Tezi_3.0b4/Console-Image-colibri-imx7.tar.xz

アプリケーションの作成

[ubuntu]$ sudo gedit ./home/root/app.sh

app.shの内容

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
#!/bin/sh
date >> /home/root/log
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

実行権限付与

[ubuntu]$ sudo chmod +x ./home/root/app.sh

アプリケーション自動実行サービスの作成

[ubuntu]$ sudo gedit ./etc/systemd/system/app.service

app.serviceの内容

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
[Unit]
Description = Application

[Service]
ExecStart = /home/root/app.sh
Type = simple

[Install]
WantedBy = multi-user.target
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

app.serviceを有効にするためにシンボリックリンク作成

[ubuntu]$ cd ./etc/systemd/system/multi-user.target.wants/
[ubuntu]$ sudo ln -s ../app.service app.service
[ubuntu]$ cd ../../../../

再度圧縮

[ubuntu]$ sudo tar -Jcvf ../Colibri-iMX7_Console-Image-Tezi_3.0b4/Console-Image-colibri-imx7.tar.xz ./

Colibri-iMX7_Console-Image-Tezi_3.0b4配下のファイルをTEZIで書き込めば/home/root/logに時刻が出力されます。

カーネルのカスタマイズ

カーネルのカスタマイズはカスタムする内容によりますが方法がいくつか考えられます。インターネット上には情報としてよくカーネルのソースコードをダウンロードして個別でコンパイルする方法の記載があります。個別でコンパイルするにはいくつかの注意を必要とします。特に注意しないといけないのがレシピ上では単純なコンパイル作業以外にもパッチを当てたりファイルを追加したり、バージョンを設定ファイルに書き込むなどさまざまな追加処理が存在します。個別でカーネルをコンパイルする場合、元の レシピの処理を読み解いて再現する必要があります。本手法はメンテナンス製が悪くレシピを読み解けなければできません。レシピの処理が多い場合は困難ですのであまり推奨はしません。



Open Embeddedに適したカーネルのカスタマイズ

bitbakeの一連の流れはソースコードのダウンロード、展開、パッチ適用、コンフィグ、コンパイルとなっています。
本マニュアルでのカスタマイズはパッチ適用のタイミングで適用されるパッチを作成することによりカーネルへの変更を加えます。



例としてカーネルの起動中のロゴと液晶の解像度をEDT 7.0 TFT WVGA用に変更するカスタムを行います。LCDを使用するアプリケーションにおいて確実に行うカスタム内容です。

下記コマンドでカーネルコンフィグするための機能をインストールしておきます。

[ubuntu]$ sudo apt-get -y install libncurses5-dev

最初にロゴファイルを作成します。

netpbmをインストール

[ubuntu]$ sudo apt-get -y install netpbm

ロゴにするBMPファイルを用意しLinuxのロゴ用のフォーマットに変換します。
本マニュアルではtest.bmpという800x480の画像ファイルを使用します。

ワーキングディレクトリ作成、移動

[ubuntu]$ mkdir -p /work/patch/kernel
[ubuntu]$ cd /work/patch/kernel

bmpからppmへ変換

[ubuntu]$ bmptopnm test.bmp > test.ppm

224色へ減色

[ubuntu]$ ppmquant 224 test.ppm > test_224.ppm

ASCIIへ変換

[ubuntu]$ pnmnoraw test_224.ppm > logo_custom_clut224.ppm

devshell

Open Embeddedではカスタムを容易にするためのdevshellというものが用意されています。

Open Embeddedの準備

[ubuntu]$ cd /work/oe-core/
[ubuntu]$. export

カーネルの初期化

[ubuntu]$ bitbake -c cleansstate virtual/kernel

devshell実行

[ubuntu]$ bitbake -c devshell virtual/kernel

カーネルのソースコードを展開したワーキングディレクトリで新しいターミナル(タブ)が開きます。
本コマンドを実行した後にlog.task_order を確認するとfetch unpack patchが行われていることがわかります。



devshellはbitbake時に設定される環境変数を再現してくれます。
例えば下記のようにCCやCFLAGSにはARM向けクロスコンパイラおよび必要なオプションが定義されています。



通常のカーネルのコンパイルと同じことが可能です。例えばmake menuconfigと入力するとカーネルコンフィグが出てきます。
ただし本マニュアルではdevshellでカーネルコンフィグを行いません。(理由は後述)
Exitで抜けてカーネルコンフィグを終了します。



カスタムを行います。下記はdevshell実行後に行います。

作成したロゴをコピーします。

[ubuntu]$ cp /work/patch/kernel/logo_custom_clut224.ppm ./drivers/video/logo/

LCDの設定を変更するためにデバイスツリーの修正を行います。

[ubuntu]$ gedit ./arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi

修正内容は下記です。(206行目)

native-mode = <&timing_vga>;
->
native-mode = <&timing_wvga>;



修正内容を確認します。

[ubuntu]$ git status

修正されたファイル

./arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi

追加されたファイル

./drivers/video/logo/logo_custom_clut224.ppm



変更点の追加削除反映

[ubuntu]$ git add -A

コミットします。コメント部分はパッチファイル名に使用されます。

[ubuntu]$ git commit -m "ChangeLogo"

パッチを作成します。

[ubuntu]$ git format-patch -n HEAD^

0001-ChangeLogo.patchというファイル名でパッチファイルが出力されます。

パッチファイルをカーネルのレシピに反映するために移動します。

[ubuntu]$ mv 0001-ChangeLogo.patch /work/oe-core/layers/meta-toradex-nxp/recipes-kernel/linux/linux-toradex-4.14-2.3.x/mx7/

/work/oe-core/layers/meta-toradex-nxp/recipes-kernel/linux/linux-toradex-4.14-2.3.x/配下にはモジュールごとにディレクトリが分かれています。該当するディレクトリに格納するとそのモジュールのみ読み込み可能なパッチになります。

/work/oe-core/layers/meta-toradex-nxp/recipes-kernel/linux/linux-toradex-4.14-2.3.x/配下に格納すると全モジュールが読み込み可能にあります。本修正はmx7専用のファイルを修正しているためmx7配下に格納しています。

devshellを終了します。devshellのターミナルが終了しbitbakeを行ったターミナルに変わります。

[ubuntu]$ exit

作成したパッチファイルをカーネルのレシピに追加します。

[ubuntu]$ gedit ../layers/meta-toradex-nxp/recipes-kernel/linux/linux-toradex_4.14-2.3.x.bbappend

追記内容

SRC_URI_append_mx7 = " file://0001-ChangeLogo.patch"

_append_mx7とすることでColibri-iMX7のみに適用するパッチになります。
SRC_URI_appendはSRC_URIと文字列を結合します。そのためfile://0001-ChangeLogo.patchの手前にスペースが必要です。



カーネルコンフィグ

ロゴを適用するにはカーネルのロゴの設定をカスタムロゴを使用するように変更する必要があります。
devshellでもカーネルコンフィグはできますがbitbake -c menuconfigを使用します。

カーネルのレシピにはSRC_URIにソースコードの取得先以外にfile://defconfigがついています。
このファイルはカーネルコンフィグの設定ファイルです。Colibri-iMX7のカーネルのレシピにも本ファイルが指定されています。
本ファイルはpreconfigureのタイミングでカーネルの設定を上書きします。devshellではfetch unpack patchまでしか行われずdefconfigが適用されていない状態ですのでパッチを作成しても上書きされてしまいますのでdefconfigそのものを変更します。

最初に初期化します。(先ほどのカーネルのカスタムを元に戻します。)

[ubuntu]$ bitbake -c cleansstate virtual/kernel

下記コマンドを実行するとカーネルコンフィグが行えます。

[ubuntu]$ bitbake -c menuconfig virtual/kernel

本コマンドを実行した後にlog.task_order を確認すると
fetch unpack patch preconfigure configure menuconfigが行われていることがわかります。

カーネルコンフィグは新しいタグで表示されます。(カーネルコンフィグの操作に関しては省略します。)
Device Drivers -> Graphics support -> Bootup logoを選択します。スペースを入力してCustom 224-color Linux logoを有効にします。



Saveを選択して設定を保存します。その後Exitを選択してカーネルコンフィグを抜けます。



もともと存在するdefconfigの退避

[ubuntu]$ mv ../layers/meta-toradex-nxp/recipes-kernel/linux/linux-toradex-4.14-2.3.x/mx7/defconfig ../layers/meta-toradexnxp/recipes-kernel/linux/linux-toradex-4.14-2.3.x/mx7/defconfig_org

先ほど作成した.configをdefconfigとしてコピーします。

[ubuntu]$ cp ./tmp/work/colibri_imx7-tdx-linux-gnueabi/linux-toradex/4.14-2.3.x+gitAUTOINC+baa6c24240-r0/build/.config ../layers/meta-toradex-nxp/recipes-kernel/linux/linux-toradex-4.14-2.3.x/mx7/defconfig

.configの所在については下記のコマンドで検索してください。

[ubuntu]$ find ./tmp/work -name .config

カーネルの初期化(一度編集した内容を元に戻します。)

[ubuntu]$ bitbake -c cleansstate virtual/kernel

イメージの作成

[ubuntu]$ bitbake console-tdx-image

出力されたファイルからOSイメージを作成してモジュールに書き込みます。

[ubuntu]$ cd /work/image/
[ubuntu]$ sudo tar -xf /work/oe-core/build/deploy/images/colibri-imx7/Colibri-iMX7_Console-Image-Tezi_3.0b4.tar

解凍したファイルの中のuEnv.txtを修正したU-Bootの設定を変更します。設定変更により画面上に出るデバッグ用出力やカーソルを消します。Colibri-iMX7の場合setupの初期値は下記です。/p>

setup=setenv setupargs console=tty1 console=${console},${baudrate}n8 ${memargs} consoleblank=0; setenv bootm_boot_mode sec

本設定はU-Bootの設定値ですがカーネルに渡すパラメータです。Linuxのロゴが表示された時に影響がある設定です。
console=tty1の設定を削除するとデバッグ用出力が消えます。vt.global_cursor_default=0を追加すると左下の点滅が消えます。下記に書き換えます。

setup=setenv setupargs console=${console},${baudrate}n8 ${memargs} consoleblank=0 consoleblank=0 vt.global_cursor_default=0; setenv bootm_boot_mode sec



uEnv.txt修正後、TEZIを利用してOSイメージを書き込むとLinux起動時のブートロゴが表示されることを確認できます。

U-Bootのカスタマイズ

本マニュアルではU-Bootのカスタム例としてU-Boot起動時のLCDのバックライトをオフにする変更とU-BootのLCDの設定をEDT7.0 TFT WVGA用に変更します。(バックライトをオフにするのはBSP3.0.4がSplashの表示に対応していないためです。)
U-Bootプログラム内のLCDの設定を変更してもU-Bootの設定が変わるわけではありません。U-Bootの設定をenv defaultで初期化した初期値が変わるだけです。
ブートローダーの仮想レシピ名はvirtual/bootloaderになります。

Open Embeddedの準備

[ubuntu]$ cd /work/oe-core/
[ubuntu]$. export

ブートローダーのレシピはbitbake -c checkuri virtual/bootloader > logで調査すると /work/oe-core/build/../layers/meta-toradex-nxp/recipes-bsp/u-boot/u-boot-toradex_2019.07.bbということがわかります。

初期化

[ubuntu]$ bitbake -c cleansstate virtual/bootloader

devshell実行

[ubuntu]$ bitbake -c devshell virtual/bootloader

LCDの設定を変更します。

[ubuntu]$ gedit ./include/configs/colibri_imx7.h

カーネルのカスタマイズでもありましたがsetupの設定からconsole=tty1を削除してvt.global_cursor_default=0を追加します。

変更箇所は内容は下記です。
168行目あたり

"setup=setenv setupargs " ¥
	"console=tty1 console=${console}" ¥
	",${baudrate}n8 ${memargs} consoleblank=0; " ¥
	"setenv bootm_boot_mode sec¥0" ¥
→
"setup=setenv setupargs " ¥
	" console=${console}" ¥
	",${baudrate}n8 ${memargs} consoleblank=0 vt.global_cursor_default=0; " ¥
	"setenv bootm_boot_mode sec¥0" ¥

同様にvideomodeを下記のように変更します。バックライトを消してSplashを表示しないため設定自体に効果はありません。
177行目あたり

"videomode=video=ctfb:x:640,y:480,depth:18,pclk:39722,le:48,ri:16,up:33,lo:10,hs:96,vs:2,sync:0,vmode:0¥0" ¥
→
"videomode=video=ctfb:x:800,y:480,depth:18,pclk:33230,le:40,ri:88,up:33,lo:10,hs:128,vs:2,sync:0,vmode:0¥0" ¥

初期処理でバックライトをOFFにします。

[ubuntu]$ gedit ./board/toradex/colibri_imx7/colibri_imx7.c

変更箇所は内容は下記です。
143行目

gpio_direction_output(GPIO_BL_ON, 1);
→
gpio_direction_output(GPIO_BL_ON, 0);

修正内容を確認します。

[ubuntu]$ git status

修正されたファイル

board/toradex/colibri_imx7/colibri_imx7.c
include/configs/colibri_imx7.h



変更点の追加削除反映

[ubuntu]$ git add -A

コミットします。コメント部分はパッチファイル名に使用されます。

[ubuntu]$ git commit -m "ChangeLCD"

パッチを作成します。

[ubuntu]$ git format-patch -n HEAD^

0001-ChangeLCD.patchというファイル名でパッチファイルが出力されます。

パッチファイルをブートローダーのレシピに反映するためにコピーします。

[ubuntu]$ cp ./0001-ChangeLCD.patch /work/oe-core/layers/meta-toradex-nxp/recipes-bsp/u-boot/files/colibri-imx7/

devshellを終了します。

[ubuntu]$ exit

下記にbbappendファイルを作成します。

[ubuntu]$ gedit /work/oe-core/layers/meta-toradex-nxp/recipes-bsp/u-boot/u-boot-toradex_2019.07.bbappend

パッチをレシピに追加します。
内容は下記です。

SRC_URI_append_mx7 = " file://0001-ChangeLCD.patch"

_append_mx7とすることでColibri-iMX7のみに適用するパッチになります。
SRC_URI_appendはSRC_URIと文字列を結合します。そのためfile://0001-ChangeLCD.patch"の手前にスペースが必要です。



Open Embeddedの準備

[ubuntu]$ cd /work/oe-core/
[ubuntu]$. export

初期化(一度編集した内容を元に戻します。)

[ubuntu]$ bitbake -c cleansstate virtual/bootloader

ブートローダーを変更してもOSイメージは作成しなおされません。一度cleansstateを実行します。

[ubuntu]$ bitbake -c cleansstate console-tdx-image

イメージの作成

[ubuntu]$ bitbake console-tdx-image

ブートローダーを変更してもOSイメージは作成しなおされません。一度cleansstateを実行します。

[ubuntu]$ bitbake -c cleansstate console-tdx-image

イメージの作成

[ubuntu]$ bitbake console-tdx-image

出力されたOSイメージをモジュールに書き込みます。

[ubuntu]$ sudo tar -xf /work/oe-core/build/deploy/images/colibri-imx7/Colibri-iMX7_Console-Image-Tezi_3.0b4.tar

OSイメージを書き込んで起動するとU-BootのSplashが表示されずLinux起動後はロゴが表示されることが確認できます。

uEnv.txtはU-Bootの修正が反映されて出力されますので修正は不要です。



デバイスツリーのカスタマイズ

デバイスツリーはOpen Embeddedのレシピによる修正で行いますが出力されたdtbファイルを後から修正することも可能です。
ただしdtb出力後は変数などが数値として出力されているため変数などを使うような修正はできません。
デバッグで簡易的に試すなどの手段としては手軽にできる方法です。

下記例ではデフォルトでSPIがCAN変換ICに使用されているのを通常のSPIとして使用するように変更する例です。

device-tree-compiler のインストール

[ubuntu]$ sudo apt-get -y install device-tree-compiler
[ubuntu]$ cd /work/image/Colibri-iMX7_Console-Image-Tezi_3.0b4

dtbファイルをdtsに変換(警告がいくつかでますが問題ありません。)

[ubuntu]$ sudo dtc -I dtb -O dts -o ./imx7d-colibri-eval-v3.dts ./imx7d-colibri-eval-v3.dtb

dtsファイルをdtbに戻します。

[ubuntu]$ sudo dtc -I dts -O dtb -o ./imx7d-colibri-eval-v3.dtb ./imx7d-colibri-eval-v3.dts

作成したdtbファイルでOSイメージを書き込めばデバイスファイルの/dev/spidev2.0ができるようになります。

記者:
桐川篤史
・岡本無線電機
ガルシアアルバロ・Toradex(トラデックス)

コメントを投稿

Please login to leave a comment!
Have a Question?