2015年03月19日

[Yocto] lm_sensorsによるIntel E3815のCPU温度測定

しばらくYocto LinuxのSato Mobile Desktop GUI関連の記事を続けてきたので、この辺で、実機ターゲットの記事を挿みます。またしても小ネタになりますが、lm_sensorsというx86系ターゲットのCPU温度を測定できるパッケージの紹介記事を書きます。

PCのCPU温度を測定するWindows用のソフトウェアはたくさん在ります。多くのマザーボード・メーカーが自社製品にこの種のソフトを添付していますし、フリーのソフトも数多く存在しています。日本ではあまり流行っていませんが、ゲーミングPCという世界があり、ゲーミングPCではCPUのオーバー・クロックを試すユーザーが多いようです。このようにユーザー側の需要が高いからか、WindowsではCPU温度を測定できることは普通のことになっています。一方、LinuxではCPU温度を測定したいという需要はそれほど高くないようです。Linux用のゲームは数が少ないでし、Linux用のPCではパフォーマンスアップより安定動作の方を重視するので、CPUのオーバー・クロックを試すユーザーは少ないからです。Windowsと同種の機能を提供するソフトは必ずLinuxにも在る言われますが、Linux用のCPU温度測定ソフトもいくつか存在します。その中でもっとも広く使われているのがlm_sensorsです。UbuntuなどPC用Linuxディストリビューションでは、lm_sensorsはアーカイブ・リポジトリ経由で簡単にインストールできます。lm_sensorsはCPUだけでなくハードディスクの温度も測定もでき、ファンの回転数も制御できます。さらに、Web経由でlm_sensorsの機能を利用するためのCGIまで含まれてます。

Yocto Linuxでは、lm_sensorsのレシピはOpenEmbeddedリポジトリに収集されています。OpenEmbeddedリポジトリからパッケージレシピを取得すると、lm_sensorsを利用できるようなりますが、lm_sensorsはカーネルが提供する機能を利用して動作するソフトウェアです。そのため、単純にパッケージをターゲットイメージへ組み込んだだけでは動作しません。以降に、DE3815TYKHE用のYocto Linuxにlm_sensorsを組み込んで、正常に動くことを確認するまでの作業録を書いていきます。

最初に、DE3815TYKHE用のbblayers.conflocal.confに以下のような設定記述を追加して、単純にlm_sensorsをcore-image-satoイメージへ組み込んでみました。
# LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
LCONF_VERSION = "6"

BBPATH = "${TOPDIR}"
BBFILES ?= ""

BBLAYERS ?= " \
/home/yuhri/Yocto/poky-daisy-11.0.2/meta \
/home/yuhri/Yocto/poky-daisy-11.0.2/meta-yocto \
/home/yuhri/Yocto/poky-daisy-11.0.2/meta-yocto-bsp \
/home/yuhri/Yocto/poky-daisy-11.0.2/meta-yocto-bsp \
/home/yuhri/Yocto/poky-daisy-11.0.2/meta-openembedded/meta-oe \
/home/yuhri/Yocto/poky-daisy-11.0.2/meta-intel \
/home/yuhri/Yocto/poky-daisy-11.0.2/meta-intel/meta-tlk \
/home/yuhri/Yocto/poky-daisy-11.0.2/meta-de3815tybe \
"
BBLAYERS_NON_REMOVABLE ?= " \
/home/yuhri/Yocto/poky-daisy-11.0.2/meta \
/home/yuhri/Yocto/poky-daisy-11.0.2/meta-yocto \
"

#
# Additional packages to be installed to the specific images
#
IMAGE_INSTALL_append_pn-core-image-sato = " \
lmsensors-libsensors \
lmsensors-sensors \
lmsensors-sensord \
lmsensors-fancontrol \
lmsensors-sensorsdetect \
lmsensors-sensorsconfconvert \
lmsensors-pwmconfig \
lmsensors-isatools \
lmsensors-config-cgi"

lm_sensorsレシピから生成されるすべてのパッケージ(*-config-*, *-doc, *-dbgパッケージを含めると、じつはこれの倍以上の数があります)をターゲットイメージへ追加しています。

パッケージ名からの推測になりますが、上記のうち、lmsensors-sensorsdetectパッケージにsensors-detectというコマンドが含まれているようです。ググって得た情報によると、このsensors-detectコマンドがターゲットハードウェアのセンサー・デバイスの種類を調べて、lm_sensorsの動作に必要なカーネルモジュールに関する設定ファイルを自動的に生成してくれるようになっているそうです。この情報に従って、lm_sensorsの全パッケージを追加したcore-image-satoイメージをDE3815TYKHEへインストールした上で、まずはターゲット上でsensors-detectコマンドを実行してみました。
# sensors-detect
# sensors-detect revision 6209 (2014-01-14 22:51:58 +0100)
# System: ????????????????????????????????? ????????????????????????????????? [?????????????????????????????????]
# Board: Intel Corporation DE3815TYKH

This program will help you determine which kernel modules you need
to load to use lm_sensors most effectively. It is generally safe
and recommended to accept the default answers to all questions,
unless you know what you're doing.

Some south bridges, CPUs or memory controllers contain embedded sensors.
Do you want to scan for them? This is totally safe. (YES/no):
modprobe: FATAL: Module cpuid not found.
Failed to load module cpuid.
Silicon Integrated Systems SIS5595... No
VIA VT82C686 Integrated Sensors... No
VIA VT8231 Integrated Sensors... No
AMD K8 thermal sensors... No
AMD Family 10h thermal sensors... No
AMD Family 11h thermal sensors... No
AMD Family 12h and 14h thermal sensors... No
AMD Family 15h thermal sensors... No
AMD Family 15h power sensors... No
AMD Family 16h power sensors... No
Intel digital thermal sensor... No
Intel AMB FB-DIMM thermal sensor... No
VIA C7 thermal sensor... No
VIA Nano thermal sensor... No

Some Super I/O chips contain embedded sensors. We have to write to
standard I/O ports to probe them. This is usually safe.
Do you want to scan for Super I/O sensors? (YES/no):

modprobe: FATAL: Module cpuid not found. Failed to load module cpuid.”というエラー・メッセージが出力されて、続く項目がすべて“No”になっているので、sensors-detectはプロセッサとチップセットの種類を特定できていないようです。これ以上継続するのは無駄だと思って、sensors-detectの処理を途中で中止しました、上のエラー・メッセージからカーネルのcpuidという機能を有効にする必要があるようです。

現在のYocto Linuxのカーネル・コンフィグレーションで検索してみると、以下のような設定項目が見つかりました。
# zcat /proc/config.gz | grep CPUID
# CONFIG_X86_CPUID is not set

bitbake linux-yocto -c menuconfig」コマンドによってカーネルのコンフィグレーション画面を開き、CONFIG_X86_CPUIDに該当する設定項目を探してみると、以下のメニュー項目がそれに該当するようです。
UBShot_20150319_145912-YoctoLinux-DE3815TYKHE-Adding_lmsensors-704x721
このメニュー項目を有効にした上で「bitbake linux-yocto -c compile -f」と「bitbake linux-yocto」コマンドを実行して、カーネルイメージの再ビルドを行いました。さらにターゲットイメージの再ビルドも行い、そのイメージをDE3815TYKHEへインストールした上で、再度sensors-detectコマンドを実行してみました。
# sensors-detect
# sensors-detect revision 6209 (2014-01-14 22:51:58 +0100)
# System: ????????????????????????????????? ????????????????????????????????? [?????????????????????????????????]
# Board: Intel Corporation DE3815TYKH

This program will help you determine which kernel modules you need
to load to use lm_sensors most effectively. It is generally safe
and recommended to accept the default answers to all questions,
unless you know what you're doing.

Some south bridges, CPUs or memory controllers contain embedded sensors.
Do you want to scan for them? This is totally safe. (YES/no):
Silicon Integrated Systems SIS5595... No
VIA VT82C686 Integrated Sensors... No
VIA VT8231 Integrated Sensors... No
AMD K8 thermal sensors... No
AMD Family 10h thermal sensors... No
AMD Family 11h thermal sensors... No
AMD Family 12h and 14h thermal sensors... No
AMD Family 15h thermal sensors... No
AMD Family 15h power sensors... No
AMD Family 16h power sensors... No
Intel digital thermal sensor... Success!
(driver `coretemp')
Intel AMB FB-DIMM thermal sensor... No
VIA C7 thermal sensor... No
VIA Nano thermal sensor... No

Some Super I/O chips contain embedded sensors. We have to write to
standard I/O ports to probe them. This is usually safe.
Do you want to scan for Super I/O sensors? (YES/no):
Probing for Super-I/O at 0x2e/0x2f
Trying family `National Semiconductor/ITE'... No
Trying family `SMSC'... No
Trying family `VIA/Winbond/Nuvoton/Fintek'... No
Trying family `ITE'... Yes
Found unknown chip with ID 0x8607
Probing for Super-I/O at 0x4e/0x4f
Trying family `National Semiconductor/ITE'... No
Trying family `SMSC'... No
Trying family `VIA/Winbond/Nuvoton/Fintek'... No
Trying family `ITE'... No

Some systems (mainly servers) implement IPMI, a set of common interfaces
through which system health data may be retrieved, amongst other things.
We first try to get the information from SMBIOS. If we don't find it
there, we have to read from arbitrary I/O ports to probe for such
interfaces. This is normally safe. Do you want to scan for IPMI
interfaces? (YES/no):
# DMI data unavailable, please consider installing dmidecode 2.7
# or later for better results.
Probing for `IPMI BMC KCS' at 0xca0... No
Probing for `IPMI BMC SMIC' at 0xca8... No

Some hardware monitoring chips are accessible through the ISA I/O ports.
We have to write to arbitrary I/O ports to probe them. This is usually
safe though. Yes, you do have ISA I/O ports even if you do not have any
ISA slots! Do you want to scan the ISA I/O ports? (YES/no):
Probing for `National Semiconductor LM78' at 0x290... No
Probing for `National Semiconductor LM79' at 0x290... No
Probing for `Winbond W83781D' at 0x290... No
Probing for `Winbond W83782D' at 0x290... No

Lastly, we can probe the I2C/SMBus adapters for connected hardware
monitoring devices. This is the most risky part, and while it works
reasonably well on most systems, it has been reported to cause trouble
on some systems.
Do you want to probe the I2C/SMBus adapters now? (YES/no):
Found unknown SMBus adapter 8086:0f12 at 0000:00:1f.3.
Sorry, no supported PCI bus adapters found.

Next adapter: i915 gmbus ssc (i2c-0)
Do you want to scan it? (yes/NO/selectively):

Next adapter: i915 gmbus vga (i2c-1)
Do you want to scan it? (yes/NO/selectively):

Next adapter: i915 gmbus panel (i2c-2)
Do you want to scan it? (yes/NO/selectively):

Next adapter: i915 gmbus dpc (i2c-3)
Do you want to scan it? (yes/NO/selectively):

Next adapter: i915 gmbus dpb (i2c-4)
Do you want to scan it? (yes/NO/selectively):

Next adapter: i915 gmbus dpd (i2c-5)
Do you want to scan it? (yes/NO/selectively):

Next adapter: DPDDC-B (i2c-6)
Do you want to scan it? (YES/no/selectively):

Next adapter: SMBus I801 adapter at e000 (i2c-7)
Do you want to scan it? (YES/no/selectively):
Client found at address 0x50
Probing for `Analog Devices ADM1033'... No
Probing for `Analog Devices ADM1034'... No
Probing for `SPD EEPROM'... No
Probing for `EDID EEPROM'... No


Now follows a summary of the probes I have just done.
Just press ENTER to continue:

Driver `coretemp':
* Chip `Intel digital thermal sensor' (confidence: 9)

Do you want to generate /etc/sysconfig/lm_sensors? (yes/NO): YES
Copy prog/init/lm_sensors.init to /etc/init.d/lm_sensors
for initialization at boot time.
You should now start the lm_sensors service to load the required
kernel modules.


cpuidに関するエラー・メッセージが消えて、最初の項目のうち“Intel digital thermal sensor...”が“Success!”に変わっているので、プロセッサとチップセットの種類を特定できているようです。これで大丈夫なのかなぁと思いながら、今度はsensors-detectの処理を継続してみました。すべてのプロンプトに対して「Enter」をタイプしながら進むと、一番最後に/etc/sysconfig/lm_sensorsという設定ファイルを作成するかどうかを問うプロンプトが表示されました。このプロンプトに「YES」と入力すると、設定ファイルの作成に成功したらしいメッセージが出力されてsensors-detectは終了しました。

sensors-detectによって作成された設定ファイルを確認すると、下のような内容でした。
# cat /etc/sysconfig/lm_sensors
# Generated by sensors-detect on Thu Mar 19 17:03:45 2015
# This file is sourced by /etc/init.d/lm_sensors and defines the modules to
# be loaded/unloaded.
#
# The format of this file is a shell script that simply defines variables:
# HWMON_MODULES for hardware monitoring driver modules, and optionally
# BUS_MODULES for any required bus driver module (for example for I2C or SPI).

HWMON_MODULES="coretemp"

設定ファイルが作成されたので、これでOKなんだろうと思って、続いてsensorsというコマンドを実行してみました。これがCPU温度の測定情報を取得するためのコマンドです。sensorsコマンドによって、以下のような情報が出力されました。
# sensors
acpitz-virtual-0
Adapter: Virtual device
temp1: +26.8 C (crit = +90.0 C)


一応CPU温度の測定値は取得できているよう見えますが、“+26.8 C”という値はちょっと低すぎるような気します。それに、sensors-detectの表示メッセージと上記の設定ファイル内の“coretemp”というのが気になりました。これもカーネルモジュール(ドライバ)だと思われるからです。

現在のカーネル・コンフィグレーションを調べると、以下のような設定項目がヒットしました。
# zcat /proc/config.gz | grep CORETEMP
# CONFIG_SENSORS_CORETEMP is not set

名前からしても、多分このCONFIG_SENSORS_CORETEMPが“coretemp”に該当するカーネルの設定項目だと思われます。上記のとおり、現在の設定では無効になっています。

ここで色々とググって調べたみたところ、Atomプロセッサでlm_sensorsを動かすには、どうやらカーネルのCONFIG_X86_MSRCONFIG_SENSORS_CORETEMPという機能を有効にしないとダメらしいことが判りました。どうやってこの結論に達したかと言うと、lm_sensors公式サイトの「Device Support Status」ページに掲載されている表中の「Intel Atom」の情報から推測しました。
ASShot_20150320_0006-YoctoLinux-DE3815TYKHE-Adding_lmsensors-1222x539
上表中の「MSR」という用語について調べてみると、これは「Model-specific Register」の略だそうで、Pentiumから追加されたプロセッサの内部機能を制御するための特殊なレジスタらしいです。Pentium M以降のプロセッサでは、このMSR経由で取得できるデータにCPU温度情報が含まれていることが判りました。もう一つの「coretemp」は、Intel Core/Core 2/Atomシリーズ・プロセッサに内蔵されているセンサー・デバイス用のドライバのようです。

上記の情報に基づいて、再度カーネルのコンフィグレーション画面を開いて、CONFIG_X86_MSRCONFIG_SENSORS_CORETEMPに該当するメニュー項目を有効にしました。
UBShot_20150319_154431-YoctoLinux-DE3815TYKHE-Adding_lmsensors-704x721
UBShot_20150319_161849-YoctoLinux-DE3815TYKHE-Adding_lmsensors-704x721
その上で、カーネルイメージとターゲットイメージの再ビルドを行いました。再ビルドによって生成されたターゲットイメージをDE3815TYKHEへインストールして、再度sensors-detectコマンドを実行してみると、前回と同様に、最後に設定ファイルの作成に成功した旨のメッセージが表示されて終了しました。sensors-detectによって作成された/etc/sysconfig/lm_sensorsの内容も同じでした。

/etc/sysconfig/lm_sensorsが作成されていることを確認した後、再度ターゲット上でsensorsコマンドを実行してみると、今度は下のような情報が表示されました。
# sensors
acpitz-virtual-0
Adapter: Virtual device
temp1: +26.8 C (crit = +90.0 C)

coretemp-isa-0000
Adapter: ISA adapter
Core 0: +48.0 C (high = +110.0 C, crit = +110.0 C)


新たに追加された下側の“+48.0 C”はCPUの温度としてそれらしい値です。“Core 0 ”というのはE3815がシングルコアであることを表しているのでしょう。これがカーネルのcoretempドライバによって取得された温度情報のようです。それにsensorsコマンドを繰り返し実行すると、この温度が変化することが確認できました。この測定値こそDE3815TYKHEに搭載されているE3815の温度のようです。

以上で、DE3815TYKHE上のYocto Linuxでlm_sensorsが動くようになりましたが、最後にlocal.confの設定記述を以下のように変更しました。
#
# Additional packages to be installed to the specific images
#
IMAGE_INSTALL_append_pn-core-image-sato = " \
lmsensors-libsensors \
lmsensors-sensors \
lmsensors-sensord \
lmsensors-sensorsdetect \
lmsensors-sensorsconfconvert \
lmsensors-isatools \
lmsensors-config-cgi"

ターゲットイメージからlmsensors-fancontrolとlmsensors-pwmconfigというパッケージを削除するためです。この2つはファンの回転数の取得と制御を行うパッケージのようですが、DE3815TYKHEにはファンは搭載されていないからです。

本記事には、カーネルの機能を利用しているlm_sensorsをターゲットイメージへ組み込んで、その機能が正常に動作していることを確認するまでの試行錯誤をそのまま書いてみました。このようなパッケージをYocto Linuxへ組み込む際の作業過程を知ってもらいたかったからです。PC用のLinuxディストリビューションではアーカイブ・リポジトリにパッケージが用意されているので、lm_sensorsのようなメジャーなソフトウェアは簡単にインストールすることができます。それ対して、組込みLinuxの開発作業では、本記事のような試行錯誤を何度も繰り返しながらシステムを構築していきます。他のIT分野のソフトウェア開発も似たようなものだと思いますが、組込みLinuxではGoogle先生への依存度が極めて高いです。もしGoogleの検索情報が存在しなかったら、にっちもさっも行かないでしょう。インターネット上に情報を上げくれたり、オープンソース・コミュニティに積極的に参加している人達、そしてGoogleへの感謝を忘れてはいけないですね。

組込みLinuxを利用している日本の企業はもっと積極的に情報を公開すべきですし、オープンソース・コミュニティへの貢献活動を忘れてはいけないと思います。オープンソースを利用して利益を上げているくせに、こういう活動を疎かにしている日本企業があまりに多すぎます。Linuxカーネルやオープンソース・ソフトウェアは何千・何万人ものプログラマの成果によって成り立っていています。Androidの構成要素はほとんどGoogleが開発したものですが、AndroidはLinuxカーネルの上で動いているので、オープンソース・コミュニティの成果の上に構築されたOSだと言えます。オープンソース・ソフトウェアを利用して利益を上げているのなら、その利益に見合った対価を払うのは当然の義務だと思います。欧米のIT企業では、オープンソース・コミュニティへの貢献度が大きい社員は高く評価されます。日本では、こういう活動はプライベートでやるべきものだという考え方が主流で、社員が企業活動の一環としてやることを禁止している会社が多いです。欧米では、オープンソース・コミュニティへの貢献は社会公益への貢献と同じだと考える人が多いようです。本当に悲しい事ですが、日本企業の本音は、社会より会社の利益の方を優先したいのでしょう。会社の理念として「社会への貢献」という項目を書いているくせに、実際には、社会公益のことなどまったく考えていないのが日本企業の実情なのかもしれません。

社会公益へ大きな貢献をすれば、その貢献を実現した社員だけでなく、社員が所属している会社も高く評価されるはずです。会社の利益にいくら貢献しても、日本企業はその貢献度に見合ったロイヤリティを社員へ払いません。会社に貢献するより社会へ貢献することを優先した方が社員にとっても有益じゃないでしょうか。社会公益に貢献して有名になれば、将来起業したり独立するときにそれが大きく効いてきます。どうせ40歳を超えたらリストラの対象になってしまうだから、大手企業で働いている社員は、もっと社会公益のことを考えてキャリアアップを優先した方が自分のためです。会社の中に埋もれてしまうより、オープンソース・コミュニティへの参加活動をどんどんやって有名になった方が勝ち組に入れるじゃないでしょうか。Developers Summitなどでスタートアップ企業の経営者の話を聞くと、ほとんどがこのパターンで独立しています。「会社に所属しているうちに、いかに社会に名を売って有名になるか」。こういう考え方で積極的に会社の外にコネクションを広げた方が、勝ち組になれる早道なんだと思えてなりません。

【2015/03/23 追記】

本記事には、DE3815TYKHE用Yocto Linuxにlm_sensorsを組み込むための作業過程を試行錯誤も含めて書きましたが、lm_sensors用のカーネル・コンフィグレーションをBSP化する方法について書いていませんでした。2014/10/25の記事にDE3815TYKHE用BSPの作成方法を掲載済みですが、このBSPのDaisy 1.6.2版(2014/12/29の記事で作成したDE3815TYKHE用BSP)へlm_sensors用の設定を追加する方法について以下に説明します。

ターゲット上でlm_sensorsが正常に動くことが確認できたら、一旦現在のカーネルのビルド状態をクリーンします。以下のコマンドによって、それができます。
% bitbake linux-yocto -c cleansstate

カーネルのビルド状態をクリーンした後、以下のコマンドを実行すると、改めてカーネルのソースが展開されます。
% bitbake linux-yocto -c kernel_configme -f

続いて、カーネルのコンフィグレーション画面を開くために、以下のコマンドを実行します。
% bitbake linux-yocto -c menuconfig

コンフィグレーション画面が開いたら、本記事で示したlm_sensors用の3つのメニュー項目を有効にします。

変更した設定内容を保存してカーネルのコンフィグレーション画面を閉じたら、続いて以下のコマンドを実行します。
% bitbake linux-yocto -c diffconfig

これによって、lm_sensors用の差分設定が格納された以下のようなfragment.cfgというコンフィグレーションフラグメント・ファイルが生成されます。
++ .config	2015-03-23 17:23:31.081557999 +0900
CONFIG_X86_MSR=y
CONFIG_X86_CPUID=y
CONFIG_SENSORS_CORETEMP=m

続いて、上で作成したfragment.cfgをDE3815TYKHE BSPのカーネル・レシビが格納されているディレクトリへリネーム・コピーします。
% mkdir ../meta-de3815tybe/recipes-kernel/linux/linux-yocto
% cp -p tmp/work/corei7-64-intel-common-poky-linux/linux-yocto/3.10.59+gitAUTOINC+8f05306a8e_747e1cbd12-r0/fragment.cfg ../meta-de3815tybe/recipes-kernel/linux/linux-yocto/add_config-enable_lmsensors.cfg

上の操作がすべて済んだら、DE3815TYKHE BSPのカーネル・レシビを以下のように書き換えます。
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"

#############################
# MACHINE = de3815tybe-32 #
#############################
COMPATIBLE_MACHINE_de3815tybe-32 = "de3815tybe-32"
KMACHINE_de3815tybe-32 = "valleyisland-32"
KBRANCH_de3815tybe-32 = "standard/base"
KERNEL_FEATURES_de3815tybe-32 = " features/valleyisland-io/valleyisland-io.scc \
features/valleyisland-io/valleyisland-io-pci.scc \
features/ciphers/ciphers.scc \
features/wifi/wifi-all.scc"

LINUX_VERSION_de3815tybe-32 = "3.10.59"
SRCREV_machine_de3815tybe-32 = "747e1cbd12b15db8bc2ae86e2359c1b113f120d6"
SRCREV_meta_de3815tybe-32 = "8f05306a8e6f5ee422d50c3317acce0cf9e6aada"
SRCREV_valleyisland-io_de3815tybe-32 = "0992d01f5f382f6da60004ef87f67ebd3ca13732"

SRC_URI_de3815tybe-32 = "git://git.yoctoproject.org/linux-yocto-3.10.git;protocol=git;nocheckout=1;branch=${KBRANCH},${KMETA},valleyisland-io-3.0;name=machine,meta,valleyisland-io"

SRC_URI_de3815tybe-32 += "file://add_config-enable_lmsensors.cfg"

#############################
# MACHINE = de3815tybe-64 #
#############################
COMPATIBLE_MACHINE_de3815tybe-64 = "de3815tybe-64"
KMACHINE_de3815tybe-64 = "valleyisland"
KBRANCH_de3815tybe-64 = "standard/base"
KERNEL_FEATURES_de3815tybe-64 = " features/valleyisland-io/valleyisland-io.scc \
features/valleyisland-io/valleyisland-io-pci.scc \
features/ciphers/ciphers.scc \
features/wifi/wifi-all.scc"

LINUX_VERSION_de3815tybe-64 = "3.10.59"
SRCREV_machine_de3815tybe-64 = "747e1cbd12b15db8bc2ae86e2359c1b113f120d6"
SRCREV_meta_de3815tybe-64 = "8f05306a8e6f5ee422d50c3317acce0cf9e6aada"
SRCREV_valleyisland-io_de3815tybe-64 = "0992d01f5f382f6da60004ef87f67ebd3ca13732"

SRC_URI_de3815tybe-64 = "git://git.yoctoproject.org/linux-yocto-3.10.git;protocol=git;nocheckout=1;branch=${KBRANCH},${KMETA},valleyisland-io-3.0;name=machine,meta,valleyisland-io"

SRC_URI_de3815tybe-64 += "file://add_config-enable_lmsensors.cfg"

module_autoload_i2c-dev = "i2c-dev"

これで、lm_sensorsを組み込むためのDE3815TYKHE BSPの改造は完了です。最終的なDE3815TYKHE BSPのファイル構成を以下に示します。

  meta-de3815tybe
|-- conf
| |-- machine
| | |-- de3815tybe-32.conf
| | `-- de3815tybe-64.conf
| `-- layer.conf
|-- recipes-bsp
| `-- formfactor
| |-- formfactor
| | |-- de3815tybe-32
| | | `-- machconfig
| | `-- de3815tybe-64
| | `-- machconfig
| `-- formfactor_0.0.bbappend
`-- recipes-kernel
`-- linux
|-- linux-yocto
| `-- add_config-enable_lmsensors.cfg
`-- linux-yocto_3.10.bbappend

この状態で以下のコマンドを実行すれば、lm_sensorsに対応したカーネルイメージをビルドすることができます。
% bitbake linux-yocto


【参考ページ】

 lm sensors - ArchWiki
 CPU/CPUID/MSR - SyncHack
posted by とみやん at 10:46| Comment(0) | TrackBack(0) | Embedded Linux > Yocto Project

2015年03月17日

[Yocto] QEMUのディスプレイ解像度を変える方法

01/16の記事以降、Yocto LinuxのSato Mobile Desktop GUI画面のスクリーンショットをいくつも掲載してきましたが、これらスクリーンショットはいずれもQEMU x86-64ターゲットのディスプレイ解像度を1024x768に設定した状態で取得したものです。Yocto Linuxでは、QEMUターゲットの標準状態のデイスプレイ解像度は640x480になっています。一体どういう方法を使って、デイスプレイの解像度を変えたのか知りたい人がいるじゃないかと思います。

小ネタのTips情報になりますが、Yocto LinuxのQEMUターゲットのデイスプレイ解像度を変更する方法について紹介しましょう。

結論を先に書いてしまうと、じつは、X11の設定ファイルの内容をいじることでQEMUターゲットのディスプレイの解像度を変えています。QEMUターゲット上でX11が動いている場合、そのディスプレイの表示画面は最終的にX11によって制御されます。X11にはxorg.conf(Yocto Linuxのターゲットでは、このファイルは/etc/X11/xorg.confに配置されます)という設定ファイルが存在しており、このファイルの中にX11が管理するモニタの設定値が記述されています。

Yocto Linux(Poky Daisy 1.6.2)ビルド環境の、X11(xorg-xserver)のレシピが格納されているディレクトリのファイル構成は以下のようになっています。

  meta
`-- recipes-graphics
`-- xorg-xserver
|-- xserver-xf86-config
| |-- qemarm
| | `-- xorg.conf
| |-- qemmips
| | `-- xorg.conf
| |-- qemmips64
| | `-- xorg.conf
| |-- qemuppc
| | `-- xorg.conf
| |-- qemush4
| | `-- xorg.conf
| |-- qemux86
| | `-- xorg.conf
| |-- qemux86-64
| | `-- xorg.conf
| `-- xorg.conf
|-- xserver-xorg
| |-- aarch64.patch
| |-- crosscompile.patch
| |-- ix_open_max_preprocessor_error.patch
| |-- macro_tweak.patch
| |-- mips64-crosscompiler.patch
| `-- xorg-CVE-2013-6424.patch
|-- xserver-xf86-config_0.1.bb
|-- xserver-xorg_1.15.0.bb
`-- xserver-xorg.inc

上記のmeta/recipes-graphics/xorg-xserver/xserver-xf86-config/qemu*ディレクトリに格納されているファイルが各QEMUターゲットで使われるxorg.confで、これらはすべて同じ内容になっています。以下にその内容を示します。
Section "Files"
EndSection

Section "InputDevice"
Identifier "Generic Keyboard"
Driver "evdev"
Option "CoreKeyboard"
Option "Device" "/dev/input/by-path/platform-i8042-serio-0-event-kbd"
Option "XkbRules" "xorg"
Option "XkbModel" "evdev"
Option "XkbLayout" "us"
EndSection

Section "InputDevice"
Identifier "Configured Mouse"
Driver "vmmouse"
Option "CorePointer"
Option "Device" "/dev/input/mice"
Option "Protocol" "ImPS/2"
Option "ZAxisMapping" "4 5"
Option "Emulate3Buttons" "true"
EndSection

Section "InputDevice"
Identifier "Qemu Tablet"
Driver "evdev"
Option "CorePointer"
Option "Device" "/dev/input/touchscreen0"
Option "USB" "on"
EndSection

Section "Device"
Identifier "Graphics Controller"
Driver "vmware"
EndSection

Section "Monitor"
Identifier "Generic Monitor"
Option "DPMS"
# 1024x600 59.85 Hz (CVT) hsync: 37.35 kHz; pclk: 49.00 MHz
Modeline "1024x600_60.00" 49.00 1024 1072 1168 1312 600 603 613 624 -hsync +vsync
# 640x480 @ 60Hz (Industry standard) hsync: 31.5kHz
ModeLine "640x480" 25.2 640 656 752 800 480 490 492 525 -hsync -vsync
# 640x480 @ 72Hz (VESA) hsync: 37.9kHz
ModeLine "640x480" 31.5 640 664 704 832 480 489 491 520 -hsync -vsync
# 640x480 @ 75Hz (VESA) hsync: 37.5kHz
ModeLine "640x480" 31.5 640 656 720 840 480 481 484 500 -hsync -vsync
# 640x480 @ 85Hz (VESA) hsync: 43.3kHz
ModeLine "640x480" 36.0 640 696 752 832 480 481 484 509 -hsync -vsync
EndSection

Section "Screen"
Identifier "Default Screen"
Device "Graphics Controller"
Monitor "Generic Monitor"
SubSection "Display"
Modes "640x480"
EndSubSection
EndSection

Section "ServerLayout"
Identifier "Default Layout"
Screen "Default Screen"
InputDevice "Generic Keyboard"
# InputDevice "Configured Mouse"
InputDevice "QEMU Tablet"
Option "AllowEmptyInput" "no"
EndSection

このxorg.confの中にはキーボード、マウス、モニタの設定項目が存在しますが、上記のハイライトの部分がX11の起動時に使われるモニタの種類と表示モードを定義しています。この定義のDisplayサブセクションのModesプロパティの設定値を変更してやれば、X11のディスプレイ解像度を変えることができます。

私がQEMUx86-64ターゲット用に作成したxorg.confと、このファイルを格納したxserver-xf86-configパッケージを作成するためのレシピファイル(meta/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbをカスタマイズするためのレシピ)を以下に公開します。
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"

Section "Files"
EndSection

Section "InputDevice"
Identifier "Generic Keyboard"
Driver "evdev"
Option "CoreKeyboard"
Option "Device" "/dev/input/by-path/platform-i8042-serio-0-event-kbd"
Option "XkbRules" "xorg"
Option "XkbModel" "evdev"
Option "XkbLayout" "us"
EndSection

Section "InputDevice"
Identifier "Configured Mouse"
Driver "vmmouse"
Option "CorePointer"
Option "Device" "/dev/input/mice"
Option "Protocol" "ImPS/2"
Option "ZAxisMapping" "4 5"
Option "Emulate3Buttons" "true"
EndSection

Section "InputDevice"
Identifier "Qemu Tablet"
Driver "evdev"
Option "CorePointer"
Option "Device" "/dev/input/touchscreen0"
Option "USB" "on"
EndSection

Section "Device"
Identifier "Graphics Controller"
Driver "vmware"
EndSection

Section "Monitor"
Identifier "Generic Monitor"
Option "DPMS"
# 1024x768i @ 43Hz (industry standard) hsync: 35.5kHz
ModeLine "1024x768" 44.9 1024 1032 1208 1264 768 768 776 817 +hsync +vsync Interlace
# 1024x768 @ 60Hz (VESA) hsync: 48.4kHz
ModeLine "1024x768" 65.0 1024 1048 1184 1344 768 771 777 806 -hsync -vsync
# 1024x768 @ 70Hz (VESA) hsync: 56.5kHz
ModeLine "1024x768" 75.0 1024 1048 1184 1328 768 771 777 806 -hsync -vsync
# 1024x768 @ 75Hz (VESA) hsync: 60.0kHz
ModeLine "1024x768" 78.8 1024 1040 1136 1312 768 769 772 800 +hsync +vsync
# 1024x768 @ 85Hz (VESA) hsync: 68.7kHz
ModeLine "1024x768" 94.5 1024 1072 1168 1376 768 769 772 808 +hsync +vsync
# 1024x768 @ 89Hz (non-standard) hsync: 72.0kHz
ModeLine "1024x768" 100 1024 1108 1280 1408 768 768 780 796 +hsync +vsync
# 1024x600 59.85 Hz (CVT) hsync: 37.35 kHz; pclk: 49.00 MHz
Modeline "1024x600_60.00" 49.00 1024 1072 1168 1312 600 603 613 624 -hsync +vsync
# 800x600 @ 56Hz (VESA) hsync: 35.2kHz
ModeLine "800x600" 36.0 800 824 896 1024 600 601 603 625 +hsync +vsync
# 800x600 @ 60Hz (VESA) hsync: 37.9kHz
ModeLine "800x600" 40.0 800 840 968 1056 600 601 605 628 +hsync +vsync
# 800x600 @ 72Hz (VESA) hsync: 48.1kHz
ModeLine "800x600" 50.0 800 856 976 1040 600 637 643 666 +hsync +vsync
# 800x600 @ 75Hz (VESA) hsync: 46.9kHz
ModeLine "800x600" 49.5 800 816 896 1056 600 601 604 625 +hsync +vsync
# 800x600 @ 85Hz (VESA) hsync: 53.7kHz
ModeLine "800x600" 56.3 800 832 896 1048 600 601 604 631 +hsync +vsync
# 640x480 @ 60Hz (Industry standard) hsync: 31.5kHz
ModeLine "640x480" 25.2 640 656 752 800 480 490 492 525 -hsync -vsync
# 640x480 @ 72Hz (VESA) hsync: 37.9kHz
ModeLine "640x480" 31.5 640 664 704 832 480 489 491 520 -hsync -vsync
# 640x480 @ 75Hz (VESA) hsync: 37.5kHz
ModeLine "640x480" 31.5 640 656 720 840 480 481 484 500 -hsync -vsync
# 640x480 @ 85Hz (VESA) hsync: 43.3kHz
ModeLine "640x480" 36.0 640 696 752 832 480 481 484 509 -hsync -vsync
EndSection

Section "Screen"
Identifier "Default Screen"
Device "Graphics Controller"
Monitor "Generic Monitor"
SubSection "Display"
Modes "1024x768"
EndSubSection
EndSection

Section "ServerLayout"
Identifier "Default Layout"
Screen "Default Screen"
InputDevice "Generic Keyboard"
# InputDevice "Configured Mouse"
InputDevice "QEMU Tablet"
Option "AllowEmptyInput" "no"
EndSection

オリジナルのxorg.confのMonitorセクションには640x480と1024x600の表示モードのエントリしか存在しなかったので、800x600と1024x768のエントリを追加しています。これらの表示モード・エントリの設定値は、X11のソースパッケージに収納されている以下のファイルから取得しました。
//
// Default modes distilled from
// "VESA and Industry Standards and Guide for Computer Display Monitor
// Timing", version 1.0, revision 0.8, adopted September 17, 1998.
//
// $XFree86: xc/programs/Xserver/hw/xfree86/etc/vesamodes,v 1.3 1999/11/16 03:28:03 tsi Exp $


# 640x350 @ 85Hz (VESA) hsync: 37.9kHz
ModeLine "640x350" 31.5 640 672 736 832 350 382 385 445 +hsync -vsync

# 640x400 @ 85Hz (VESA) hsync: 37.9kHz
ModeLine "640x400" 31.5 640 672 736 832 400 401 404 445 -hsync +vsync

# 720x400 @ 85Hz (VESA) hsync: 37.9kHz
ModeLine "720x400" 35.5 720 756 828 936 400 401 404 446 -hsync +vsync

# 640x480 @ 60Hz (Industry standard) hsync: 31.5kHz
ModeLine "640x480" 25.175 640 656 752 800 480 490 492 525 -hsync -vsync

# 640x480 @ 72Hz (VESA) hsync: 37.9kHz
ModeLine "640x480" 31.5 640 664 704 832 480 489 492 520 -hsync -vsync

# 640x480 @ 75Hz (VESA) hsync: 37.5kHz
ModeLine "640x480" 31.5 640 656 720 840 480 481 484 500 -hsync -vsync

# 640x480 @ 85Hz (VESA) hsync: 43.3kHz
ModeLine "640x480" 36.0 640 696 752 832 480 481 484 509 -hsync -vsync

# 800x600 @ 56Hz (VESA) hsync: 35.2kHz
ModeLine "800x600" 36.0 800 824 896 1024 600 601 603 625 +hsync +vsync

# 800x600 @ 60Hz (VESA) hsync: 37.9kHz
ModeLine "800x600" 40.0 800 840 968 1056 600 601 605 628 +hsync +vsync

# 800x600 @ 72Hz (VESA) hsync: 48.1kHz
ModeLine "800x600" 50.0 800 856 976 1040 600 637 643 666 +hsync +vsync

# 800x600 @ 75Hz (VESA) hsync: 46.9kHz
ModeLine "800x600" 49.5 800 816 896 1056 600 601 604 625 +hsync +vsync

# 800x600 @ 85Hz (VESA) hsync: 53.7kHz
ModeLine "800x600" 56.3 800 832 896 1048 600 601 604 631 +hsync +vsync

# 1024x768i @ 43Hz (industry standard) hsync: 35.5kHz
ModeLine "1024x768" 44.9 1024 1032 1208 1264 768 768 776 817 +hsync +vsync Interlace

# 1024x768 @ 60Hz (VESA) hsync: 48.4kHz
ModeLine "1024x768" 65.0 1024 1048 1184 1344 768 771 777 806 -hsync -vsync

# 1024x768 @ 70Hz (VESA) hsync: 56.5kHz
ModeLine "1024x768" 75.0 1024 1048 1184 1328 768 771 777 806 -hsync -vsync

# 1024x768 @ 75Hz (VESA) hsync: 60.0kHz
ModeLine "1024x768" 78.75 1024 1040 1136 1312 768 769 772 800 +hsync +vsync

# 1024x768 @ 85Hz (VESA) hsync: 68.7kHz
ModeLine "1024x768" 94.5 1024 1072 1168 1376 768 769 772 808 +hsync +vsync

# 1152x864 @ 75Hz (VESA) hsync: 67.5kHz
ModeLine "1152x864" 108.0 1152 1216 1344 1600 864 865 868 900 +hsync +vsync

# 1280x960 @ 60Hz (VESA) hsync: 60.0kHz
ModeLine "1280x960" 108.0 1280 1376 1488 1800 960 961 964 1000 +hsync +vsync

# 1280x960 @ 85Hz (VESA) hsync: 85.9kHz
ModeLine "1280x960" 148.5 1280 1344 1504 1728 960 961 964 1011 +hsync +vsync

# 1280x1024 @ 60Hz (VESA) hsync: 64.0kHz
ModeLine "1280x1024" 108.0 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync

# 1280x1024 @ 75Hz (VESA) hsync: 80.0kHz
ModeLine "1280x1024" 135.0 1280 1296 1440 1688 1024 1025 1028 1066 +hsync +vsync

# 1280x1024 @ 85Hz (VESA) hsync: 91.1kHz
ModeLine "1280x1024" 157.5 1280 1344 1504 1728 1024 1025 1028 1072 +hsync +vsync

# 1600x1200 @ 60Hz (VESA) hsync: 75.0kHz
ModeLine "1600x1200" 162.0 1600 1664 1856 2160 1200 1201 1204 1250 +hsync +vsync

# 1600x1200 @ 65Hz (VESA) hsync: 81.3kHz
ModeLine "1600x1200" 175.5 1600 1664 1856 2160 1200 1201 1204 1250 +hsync +vsync

# 1600x1200 @ 70Hz (VESA) hsync: 87.5kHz
ModeLine "1600x1200" 189.0 1600 1664 1856 2160 1200 1201 1204 1250 +hsync +vsync

# 1600x1200 @ 75Hz (VESA) hsync: 93.8kHz
ModeLine "1600x1200" 202.5 1600 1664 1856 2160 1200 1201 1204 1250 +hsync +vsync

# 1600x1200 @ 85Hz (VESA) hsync: 106.3kHz
ModeLine "1600x1200" 229.5 1600 1664 1856 2160 1200 1201 1204 1250 +hsync +vsync

# 1792x1344 @ 60Hz (VESA) hsync: 83.6kHz
ModeLine "1792x1344" 204.8 1792 1920 2120 2448 1344 1345 1348 1394 -hsync +vsync

# 1792x1344 @ 75Hz (VESA) hsync: 106.3kHz
ModeLine "1792x1344" 261.0 1792 1888 2104 2456 1344 1345 1348 1417 -hsync +vsync

# 1856x1392 @ 60Hz (VESA) hsync: 86.3kHz
ModeLine "1856x1392" 218.3 1856 1952 2176 2528 1392 1393 1396 1439 -hsync +vsync

# 1856x1392 @ 75Hz (VESA) hsync: 112.5kHz
ModeLine "1856x1392" 288.0 1856 1984 2208 2560 1392 1393 1396 1500 -hsync +vsync

# 1920x1440 @ 60Hz (VESA) hsync: 90.0kHz
ModeLine "1920x1440" 234.0 1920 2048 2256 2600 1440 1441 1444 1500 -hsync +vsync

# 1920x1440 @ 75Hz (VESA) hsync: 112.5kHz
ModeLine "1920x1440" 297.0 1920 2064 2288 2640 1440 1441 1444 1500 -hsync +vsync


Yocto Linuxでcore-image-satoのようなX11の機能を含むイメージをビルドすると、ターゲットイメージのビルド処理の過程でX11のソースパッケージがダウンロードされて展開されますが、上記はその展開先に存在するファイルを示しています。

xorg.conf内のMonitorセクションに1024x768より高い解像度の表示モード・エントリを追加した上で、それ使うようにDisplayサブセクションを定義しても、設定どおりのディスプレイ解像度で動作することも確認しました。上記のxorg.confの内容は物理的なモニタには依存していないので、どのQEMUターゲットでも使えるはずです。

ただし、Yocto Linuxの開発ホスト機としてVMwareの仮想マシンを利用している場合は注意が必要です。この場合、仮想マシン(QEMUから観たホスト側)のディスプレイはVMwareによって管理されており、その物理画面(仮想マシンのディスプレイ画面)はVMwareのディスプレイドライバによって制御されています。VMware仮想マシン上でQEMUが動いている場合、VMware側のディスプレイドライバのバージョンが古いと、xorg.confのDisplayサブセクションの設定値がQEMUのウィンドウ(モニタ)へ反映されないことがあります。このような環境では、VMwareとVMware Toolsはできるだけ最新バージョンのものを使った方で良いようです。

このアドバイスは実体験に基づいています。私の場合Mac上のVMware Fusionを利用しており、仮想マシンのUbuntu 12.04.1上にYocto Linuxビルド環境を構築しています。最近VMware Fusionのバージョンを5から7にアップグレードしたのですが、VMware Fusionをアップグレードする前の仮想マシンでは、上記とおりにxorg.confを変更しても、ディスプレイ解像度が640x480でQEMU x86-64ターゲットのウィンドウが開いてしまう現象が頻発していました。なぜこのような現象が起きるのかずっと原因が判らなかったのですが、VMware Fusion 7にアップグレートしたらこの現象がまったく起きなくなりました。VMware Fusion 7では、xorg.confの設定内容が反映されて常に1024x768の解像度でQEMUのウィンドウが開いています。VMware Fusionのアップグレードによって明確な差が生まれているので、QEMUとVMwareのディスプレイドライバの間に何からの因果関係が存在するとしか考えられません。

最後に、Sato GUIの表示画面にどれくらい差があるのか確認するために、QEMU x86-64ターゲットのディスプレイ解像度を変えながらスクリーンショットを撮ってみました。
UBShot_20150317_171230-Yocto_Modifying_QEM_X11-DisplayResolution-642x509
UBShot_20150317_171532-Yocto_Modifying_QEM_X11-DisplayResolution-802x629
UBShot_20150317_171820-Yocto_Modifying_QEM_X11-DisplayResolution-1026x629
UBShot_20150317_172054-Yocto_Modifying_QEM_X11-DisplayResolution-1026x797
一番上から、640x480、800x600、1024x600、1024x768に設定しています(上に掲載しているのは縮小サイズ版ですが、各スクリーンショットの画像に実サイズ版のリンクを貼ってあります)。やはりディスプレイ解像度による差は大きいことが一目瞭然ですね。

X11の設定ファイルを変更するだけのTipsですが、上のスクリーンショットが示しているとおり、その効果は絶大です。Yocto Linuxを使って組込みLinuxシステムの開発をやっている人にとって、本記事の内容が役に立てば幸いです。

【2015/03/21 追記】

本記事ではYocto LinuxのX11ベースのGUIイメージのディスプレイ解像度を変更する方法について説明しましたが、コンソール・ベースのCLIイメージのディスプレイ解像度を変える方法についても説明しておかないと片手落ちかと思います。GUIイメージと比較して需要はずっと低いかと思いますが、CLIイメージのディスプレイ解像度を変える方法について以下に記します。

QEMUターゲットを起動するのにrunqemuというコマンドを使いますが、CLIイメージを実行する場合に、runqemuコマンドに以下のようなパラメータとオプションを指定してやると、QEMUターゲットのモニタの表示モードを変更することができます。
% runqemu <MACHINE> <IMAGE> bootparams="uvesafb.mode_option=<DISPLAY_MODE>"

例えば、QEMU x86-64ターゲットを使ってcore-image-full-cmdlineイメージを1024x768 32ビット・カラー・モードで起動したい場合は、以下のようなコマンドによってそれができます。
% runqemu qemux86-64 core-image-full-cmdline bootparams="uvesafb.mode_option=1024x768-32"

runqemuコマンドをオプション指定なし実行すると、Terminalウィンドウに以下のような起動情報が出力されますが、これがrunqemuコマンドのデフォルトのオプションです。
UBShot_20150321_195605-Yocto_Modifying_QEM_VGA-DisplayResolution-704x631
--append "vga=0 uvesafb.mode_option=640x480-32 ..."」というオブションが存在しますが、これがQEMUターゲットのデフォルトのモニタ表示モードに相当します。

bootparams="uvesafb.mode_option=1024x768-32"」というオブションを指定することで、runqemuコマンドの起動情報出力は以下のように変わります。
UBShot_20150321_200051-Yocto_Modifying_QEM_VGA-DisplayResolution-704x631
つまりカーネルパラメータの「uvesafb.mode_option=」の設定値を上書きしていることになります。結果として、QEMUターゲットのモニタの表示モードが変更される訳です。

参考のために、QEMU x86-64ターゲット上で動作しているcore-image-full-cmdlineの640x480と1024x768のスクリーンショットを掲載しておきます。
UBShot_20150321_195825-Yocto_Modifying_QEM_VGA-DisplayResolution-642x509
UBShot_20150321_200119-Yocto_Modifying_QEM_VGA-DisplayResolution-1026x797
posted by とみやん at 14:44| Comment(0) | TrackBack(0) | Embedded Linux > Yocto Project

2015年02月28日

[Yocto] Sato Mobile Desktopの日本語表示化 (2)

前記事から1ヶ月も間が空いてしましいました。体調を崩して寝込んでしまう日が続いたり、本業の仕事がなかなか切りがつかなかったりで記事を書く時間が取れませんでした。今週に入って、花粉症の症状も出ています。季節の変わり目だからか、私は2〜3月に体調を崩すことが多いです。持病のヘルニア腰痛も3〜5月に症状が悪化することが多く、さらに花粉症にも苦しめられるので、私は一年の中でこの時期が一番嫌いです。ここ数年は季節の変わり目に必ず体調を崩すようになってしまいました。まだ老年期ではないですが、これから歳を重ねると、気候の変化にさえ身体が耐えられなくなってくるんだなぁと感じています。

さて、前記事に続いて、Yocto LinuxのSato Mobile Desktopの日本語表示化について書きます。

前記事では、core-image-satoイメージへ日本語TrueTypeフォントを組み込む方法について説明しました。これによって、Midoriブラウザでは日本語文字が表示できるようになりました。Midoriのような表示フォントを変更できるアプリでは、ターゲットイメージに日本語TrueTypeフォントさえ組み込めば、アプリ側でフォント設定を変更することで日本語の表示ができるようになります。

それでは、Sato GUI自体を日本語表示に対応させるにはどうすれば良いのでしょうか。じつは、これを実現する事はすごく簡単なのです。すでに日本語TrueTypeフォントを組み込み済みなら、ターゲット上で以下の手順の操作を行うだけです。
  1. Sato GUIからAppearanceアプリを起動します。すると、下のようなウィンドウが表示されます。
    UBShot_20150228_143005-Japanese_Localizing-Yocto_Sato_Desktop-QEMUx86_64-1026x797
    このウィンドウの[Appearance]メニューから[Sato]という項目を選択した上で、(現在の設定フォントを示している)[Font]ボタンをクリックします。


  2. すると、下のような[Pick a Font]ウィンドウが開くので、フォントの一覧から日本語文字のタイプフェースを含むフォントを選択した上で、[OK]ボタンを押します。
    UBShot_20150228_143236-Japanese_Localizing-Yocto_Sato_Desktop-QEMUx86_64-1026x797

  3. すると、下のように、Sato GUIのDesktopウィンドウの表示フォントが選択したものに設定されます。
    UBShot_20150228_143259-Japanese_Localizing-Yocto_Sato_Desktop-QEMUx86_64-1026x797

上記の手順の操作によって、Sato GUIは設定したフォントで表示されるようになりますが、これはGUI上の表示を変えただけです。システムや個々のアプリは、フォント情報の他にロケール情報というものを持っています。

Yocto Linuxにおいてシステム全体のロケール情報を変えるには、ターゲット上に以下のような内容の~/.profile(/home/root/.profile)というファイルを作成する必要があります。
# vi ~/.profile
export LC_ALL=ja_JP.UTF-8

この~/.profileを作成した後、Yocto Linuxを再起動すると、Sato GUIは下のような表示に変わります。
UBShot_20150228_143621-Japanese_Localizing-Yocto_Sato_Desktop-QEMUx86_64-1026x797
ご覧のとおり、一部のアプリのタイトルやヘルプが日本語で表示されています。タイトルやヘルプが英語表示のままのアプリは、日本語のロケール情報を持っていないんだと思います。~/.profile内の「export LC_ALL=ja_JP.UTF-8」という記述は、システム全体に適用されるロケール情報(システム・ロケール)を変更するための設定です(環境変数LC_ALLが未設定の場合のデフォルト値は「LC_ALL=C」になります。Cというは、すべての文字が1バイトのASCIIコードだけで表現されるロケールです)。このように設定すると、日本語のロケール情報を持っているアプリでは、アプリ内のメニューやメッセージなどで日本語が使われるようになります。例えば、ファイルマネージャ(File Manager)は下のように表示になります。
UBShot_20150301_125112-Japanese_Localizing-Yocto_Sato_Desktop-QEMUx86_64-1026x797
UBShot_20150301_125552-Japanese_Localizing-Yocto_Sato_Desktop-QEMUx86_64-1026x797
上側が表示フォントと環境変数LC_ALLの設定値を変更する前、下側がこれらを変更した後のスクリーンショットです。

ちなみに、上記で作成した~/.profileというファイルは、Yocto Linuxの起動時に実行されるログイン・スクリプトの一つです。Yocto Linuxのデフォルトのログイン・シェルはbash(Bourne-Again Shell)ではなく、ash(Almquist Shell)というものです。ashはbashとほぼ互換の機能を持っていながら、bashより軽量なため、組込みLinuxで採用されることの多いシェルです。

じつは、Sato GUIの日本語表示化のためのターゲット側の設定はこれで終わりなのです。ただし、Yocto Linuxの日本語表示用構成要素としてはこれだけでは不完全です。何が不完全なのかと言うと、このままではCLI環境用のプログラムが依然日本語の表示ができない状態になっています。

上記のシステム・ロケール設定を変更した状態でTerminalウィンドウを開くと、下のような「setlocale LC_ALL=ja_JP.UTF-8」に失敗した旨のエラー・メッセージが表示されます。
UBShot_20150228_191235-Japanese_Localizing-Yocto_Sato_Desktop-QEMUx86_64-1026x797
そして、Terminalウィンドウの中で日本語の文字を含むテキストファイルを出力すると、上のように、文字化けした状態で表示されてしまいます(このテキストファイルはscpを使ってQEMU x86-64ターゲットへ転送しました)。じつは、このTerminalウィンドウの表示フォントは、すでに上記の手順の操作によって設定した日本語のフォント(Sazanami Gothic Gothic-Reqular 9pt)になっています。それなのに、日本語文字を表示することができません。その原因は、システム上にCLI環境用の日本語のロケール情報が存在していないからです。Yocto Linuxのシステム上のCLI環境用のロケール情報の有無は、以下のコマンドによって確認できます。
# rpm -qa | grep locale
eglibc-binary-localedata-en-gb-2.19-r0.core2_64
eglibc-binary-localedata-en-us-2.19-r0.core2_64
locale-base-en-gb-2.19-r0.core2_64
locale-base-en-us-2.19-r0.core2_64
pcmanfm-locale-en-gb-1.1.2-r0.core2_64
gstreamer-locale-en-gb-0.10.36-r2.core2_64
aspell-locale-en-gb-0.60.6.1-r1.core2_64
libwebkitgtk-1.0-locale-en-gb-1.8.3-r1.core2_64
libglib-2.0-locale-en-gb-2.38.2-r0.core2_64
midori-locale-en-gb-0.5.5-r0.core2_64
gst-plugins-base-locale-en-gb-0.10.36-r8.core2_64
gtk+-locale-en-gb-2.24.22-r0.core2_64
gdk-pixbuf-locale-en-gb-2.30.3-r0.core2_64
eglibc-locale-en-gb-2.19-r0.core2_64
libatk-1.0-locale-en-gb-2.10.0-r0.core2_64
libfm-locale-en-gb-1.1.2.2-r0.core2_64
libexif-locale-en-gb-0.6.21-r0.core2_64
gst-plugins-good-locale-en-gb-0.10.31-r8.core2_64
avahi-locale-en-gb-0.6.31-r11.1.core2_64
xkeyboard-config-locale-en-gb-2.11-r0.core2_64
libsoup-2.4-locale-en-gb-2.45.3-r0.core2_64
glib-networking-locale-en-gb-2.38.0-r0.core2_64
vte-locale-en-gb-0.28.2-r6.core2_64
gconf-locale-en-gb-3.2.6-r0.core2_64

上のとおり、デフォルト状態のYocto Linuxにはen_GB.UTF-8とen_US.UTF-8のロケール情報(ロケール・パッケージ)しか含まれていません。

Sato GUIのTerminalウィンドウ内でも日本語を表示できるようにするには、ja_JP.UTF-8のロケール情報をターゲットイメージへ組み込まなくてはなりません。それを行うには、local.confに以下のような設定記述を追加します。
#
# IMAGE_LINGUAS controls what locales should be included in images.
#
IMAGE_LINGUAS ?= "en-us ja-jp"

この設定を追加した後にcore-image-satoの再ビルドを行い、新しい生成されたイメージを起動すると、下のように、en_GB.UTF-8に代わってja_JP.UTF-8のロケール・パッケージがシステムへ追加されていることが確認できます。
# rpm -qa | grep locale
eglibc-binary-localedata-en-us-2.19-r0.core2_64
eglibc-binary-localedata-ja-jp-2.19-r0.core2_64
locale-base-en-us-2.19-r0.core2_64
locale-base-ja-jp-2.19-r0.core2_64
libatk-1.0-locale-ja-2.10.0-r0.core2_64
shadow-locale-ja-4.1.4.3-r14.core2_64
binutils-locale-ja-2.24-r0.core2_64
glib-networking-locale-ja-2.38.0-r0.core2_64
gdk-pixbuf-locale-ja-2.30.3-r0.core2_64
midori-locale-ja-0.5.5-r0.core2_64
alsa-utils-locale-ja-1.0.27.2-r0.core2_64
aspell-locale-ja-0.60.6.1-r1.core2_64
libsoup-2.4-locale-ja-2.45.3-r0.core2_64
libglib-2.0-locale-ja-2.38.2-r0.core2_64
rpm-locale-ja-5.4.9-r63.core2_64
leafpad-locale-ja-0.8.18.1-r2.core2_64
sudo-locale-ja-1.8.9p5-r0.core2_64
libexif-locale-ja-0.6.21-r0.core2_64
pcmanfm-locale-ja-1.1.2-r0.core2_64
avahi-locale-ja-0.6.31-r11.1.core2_64
libgpg-error-locale-ja-1.12-r0.core2_64
gst-plugins-good-locale-ja-0.10.31-r8.core2_64
gst-plugins-base-locale-ja-0.10.36-r8.core2_64
gstreamer-locale-ja-0.10.36-r2.core2_64
util-linux-locale-ja-2.24.1-r0.core2_64
gconf-locale-ja-3.2.6-r0.core2_64
gtk+-locale-ja-2.24.22-r0.core2_64
xkeyboard-config-locale-ja-2.11-r0.core2_64
libfm-locale-ja-1.1.2.2-r0.core2_64
libpopt-locale-ja-1.16-r3.core2_64
elfutils-locale-ja-0.148-r11.core2_64
vte-locale-ja-0.28.2-r6.core2_64
eglibc-locale-ja-2.19-r0.core2_64

すべてのプログラムが必ずロケール情報を持っている訳ではありません。またロケール情報を持っているプログラムでも、日本語(ja_JP.UTF-8)に対応していないものがほとんどです。

この状態でSato GUIからTerminalウィンドウを開くと、今度はsetlocaleのエラー・メッセージは表示されません。そして、日本語文字を含むテキストファイルを出力すると、ちゃんと正常に表示されます。
UBShot_20150228_192557-Japanese_Localizing-Yocto_Sato_Desktop-QEMUx86_64-1026x797
以上で、Yocto LinuxのSato Mobile Desktopの日本語表示化は終わりです。

上手く行くんだろうかろうかと思いながら、色々と下調べをしたのですが、実際に挑戦してみると、意外に簡単にYocto Linuxの日本語表示化ができてしまったので驚いています。もっと多くの障害に遭遇するんじゃないかと想像していました。LinuxやX11の多言語対応機能が進化していて、それらの成果がYocto Linuxにも盛り込まれているから、こんなに簡単にできたのでしょう。やはりLinuxは素晴らしいですね。

Yocto Linuxの日本語表示化が出来てしまったので、日本語入力機能の実装にも意欲が湧いてきました。何とかこちらも実現したいと思っています。日本語入力機能が実装できたら、私家版の日本語版Yocto Linuxディストリビューションを制作して、これをGitHub上に置いて公開しようと計画しています。いつ頃この計画を実現できるかまだ見通しは立っていませんが、そう遠くない未来には何とか実現したいです。乞うご期待ください。
posted by とみやん at 16:53| Comment(0) | TrackBack(0) | Embedded Linux > Yocto Project

2015年01月25日

[Yocto] Sato Mobile Desktopの日本語表示化 (1)

前記事では、Yocto LinuxのSato Mobile Desktop GUI環境へMidoriブラウザを組み込む方法について紹介しました。いまや一般用途向けの機器では、Webブラウザは必須のアプリケーションだと言えます。カラオケ端末機みたいな一般ユーザに操作してもらうことが前提の機器はハードの中身がPC互換機になっていて、DebianやUbuntuのようなPC向けのLinuxディストリビューションをカスタマイズして利用しているケースが結構あります。Webブラウザを組み込むことができるのなら、このような機器でYocto Linuxを利用してシステムを構築する道が拓けてくるんじゃないでしょうか。PC向けのLinuxディストリビューションと比較すると、組込みLinuxのメモリやディスク容量などのシステム動作条件はずっと低くなり、x86 PC互換機以外のARM、MIPS、PowerPCなどを搭載したハードを使って一般ユーザが操作する機器やコンシューマ向けの機器を開発することができます。いまさら言うまでもありませんが、実際にこのような機器では組込みLinuxが広く使われています。

ここ数年でSoCプロセッサの製造単価はさらに下がっていて、アマチュアの電子工作愛好家でさえ高性能なプロセッサを安価に入手できるようになっています。IntelもPCやタブレット用だけでになく組込み向けプロセッサの種類を増やしています。そのため、従来はマイコンを使っていたローエンド機器でも高性能なx86やARMコア・プロセッサへの切り換えがどんどん進んでいます。世の中ではIoT(Internet of Things)いうトレンド・ワードが持て囃されていますが、Rasberry PiやBeagleBone BlackようなLinuxやAndroidが動くボードが3〜8千円で買える時代なのに(これらの製造単価は販売価格の2/3〜4/5程度ではないかと想像できます)、マイコンやITRONを使ってIoTデバイスを開発するのはナンセンスだと思います。単機能なセンサやビーコン・デバイスならマイコンを使うのも有りだと思いますが、複合機能が要求されるIoTデバイスではLinuxを使わないと開発工数が大きくなってしまいます。IoTデバイスのデファクト・スタンダードOSはLinuxであると言い切っても良いんじゃないでしょうか。ITRONの基本構成要素はカーネルだけであり、TCP/IPプロトコル・スタックはユーザーが移植する必要があります。ファイルシステムやその他のミドルウェアもすべて同様です。LinuxならOSの移植が完了した時点でこれらがすべて揃っていて、市販のボードならメーカーが移植済みのLinuxやAndroidのBSPを必ず配布しています(LinuxやAndroidを移植しないと、ボードが売れないからですが)。アプリを開発するにしても、ITRONのシステムコールは美的センスの欠片もなく変梃りんで、C++やJavaなどのオブジェクト指向言語からITの世界に入ったプログラマとっては「なんじゃこりゃぁあ!」と叫びたくなるような世界です。Linuxならグローバル・スタンダードであるUnixの流儀でアプリを開発することができ、豊富なライブラリや上質のサンプルコードがインターネット経由でたくさん手に入ります。いま流行りのJavaScriptを使えば、アプリ開発の工数はさらに小さくなります。LinuxとITRONを比較すると、天と地ほどの差があることは一目瞭然です。私は5年前までITRON関連の開発に係わっていましたが、ここ3年ほど新規の製品開発プロジェクトでITRONが採用された例を聞いたことがありません。ローエンド組込みの世界から離脱して情報収集をしなくなったからかもしれませんが、ITRONが衰退に向かっていることには確信を持っています。

またしても話が大きく逸れてしまいました。IoTについては色々と思う所があるので別の記事でまた書きたいと思っています。話題をYocto Linuxの技術的な情報に戻します。

さて、いままでの記事にSato Mobile Desktop GUIのスクリーンショットを掲載してきましたが、それらには日本語が表示されているものが一つも存在していないことに気づいた方がいるんじゃないでしょうか。じつは、デフォルト状態のSato GUI環境は日本語表示に対応していません。日本語のフォントとロケール情報の両方がcore-image-satoイメージに組み込まれていないからです。このため、Desktopウィンドウを含むすべてのアプリにおいて日本語を表示することができません。例えば、Midoriによって日本語を含むページを開くと、下のように日本語の文字がすべて文字化けした状態で表示されてしまいます(こういう□だらけの表示を「トウフ状態表示」と呼ぶらしいです)。
UBShot_20150125_185320-Adding_TTF-Yocto_Sato_Desktop-QEMUx86_64-1026x797
Yocto Linuxを使い始めた当初から日本語に対応していないことには気づいていて、その対応方法をずっと探していました。やっとSato GUI環境の日本語化に成功したので、その成果を記事として公開します。ただし、本記事に書く内容は、Sato GUI環境を日本語表示に対応させる方法だけです。日本語入力の方はまだ組み込みに成功していません。じつは、本記事の結論に到達するのに試行錯誤を数回繰り返しているのですが、結論だけを読むと、Sato GUI環境の日本語表示への対応は容易に実現できることが判ります。これと比較して、日本語入力の方は結構難易度が高そうな感じです。日本語入力機能の実現方法についても調べいるのですが、まだ具体的な作業は行っていません。そのため、Sato GUI環境へ日本語入力機能を追加する方法について記事を投稿できるのは少し先になりそうです。

■ TrueTypeフォントの追加組込み


まずは、Sato GUI環境へTrueTypeフォントを追加する方法から紹介します。

じつは、Yocto Linuxの配布パッケージには以下の2種類のTrueTypeフォントしか収納されていません。
    liberation-fonts
ttf-bitstream-vera

このうち、デフォルト状態のSato GUI環境に組み込まれているのはliberation-fontsだけです。DesktopウィンドウのAppearanceアイコンを開くと、Sato GUIで利用可能なTrueTypeフォントの種類を確認できます。
UBShot_20150125_184746-Adding_TTF-Yocto_Sato_Desktop-QEMUx86_64-1026x797
UBShot_20150125_184811-Adding_TTF-Yocto_Sato_Desktop-QEMUx86_64-1026x797
上記の2つはいずれも英語文字のタイプフェースしか含まれていないフォントです。Midoriブラウザで日本語のページが文字化けしてしまう原因は、日本語のTrueTypeフォントがシステム上に存在していないからです。

それでは、Yocto Linuxで利用可能な日本語のTrueTypeフォントはどこに在るのかと言うと、じつは、OpenEmbeddedリポジトリの方に存在しています。OpenEmbeddedリポジトリに以下のTrueTypeフォントが収集されており、同リポジトリからパッケージレシピを取得すると、これらのフォントが利用できるようになります。
    ttf-arphic-uming
ttf-dejavu
ttf-droid
ttf-gentium
ttf-hunky
ttf-inconsolata
ttf-liberation
ttf-mplus
ttf-sazanami
ttf-ubuntu-font-family
ttf-wqy-zenhei

上のうち、ttf-droid, ttf-mplus, ttf-sazanamiの3つのフォントが日本語文字のタイプフェースを含んでいます。これらのフォントのいずれかをシステムへ組み込めば、Sato GUI環境で日本語の文字を表示できるようになります。以降に、その具体的な方法を説明していきます。

最初に、OpenEmbeddedリポジトリのパッケージレシピを利用可能にするために、bblayers.confに下ような変更を加えてください。
# LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
LCONF_VERSION = "6"

BBPATH = "${TOPDIR}"
BBFILES ?= ""

BBLAYERS ?= " \
/home/yuhri/Yocto/poky-daisy-11.0.2/meta \
/home/yuhri/Yocto/poky-daisy-11.0.2/meta-yocto \
/home/yuhri/Yocto/poky-daisy-11.0.2/meta-yocto-bsp \
/home/yuhri/Yocto/poky-daisy-11.0.2/meta-openembedded/meta-oe \
"
BBLAYERS_NON_REMOVABLE ?= " \
/home/yuhri/Yocto/poky-daisy-11.0.2/meta \
/home/yuhri/Yocto/poky-daisy-11.0.2/meta-yocto \
"

これは、OpenEmbeddedリポジトリから取得したパッケージレシピ群が~/Yocto/poky-daisy-11.0.2/meta-openembedded/に格納されていることを前提としています。

そして、さらにlocal.confへ以下のような設定定義を追加すると、ttf-bitstream-veraに加えてOpenEmbeddedリポジトリの全TrueTypeフォントをcore-sato-imageイメージへ組み込むことができます(フォントは必要に応じて選択すれば良いのですが、今回はあえて全部のフォントを組み込んでみました)。
#
# TrueType fonts to be installed to images
#
IMAGE_TTF_FONTS = "\
ttf-bitstream-vera \
ttf-arphic-uming \
ttf-dejavu-sans ttf-dejavu-sans-mono ttf-dejavu-sans-condensed ttf-dejavu-serif ttf-dejavu-serif-condensed ttf-dejavu-common \
ttf-droid-sans ttf-droid-sans-mono ttf-droid-sans-fallback ttf-droid-sans-japanese ttf-droid-serif \
ttf-gentium ttf-gentium-alt \
ttf-hunky-sans ttf-hunky-serif \
ttf-inconsolata \
ttf-liberation-mono ttf-liberation-sans ttf-liberation-serif \
ttf-mplus-1c-black ttf-mplus-1c-bold ttf-mplus-1c-heavy ttf-mplus-1c-light ttf-mplus-1c-medium ttf-mplus-1c-regular ttf-mplus-1c-thin \
ttf-mplus-1m-bold ttf-mplus-1m-light ttf-mplus-1m-medium ttf-mplus-1m-regular ttf-mplus-1m-thin \
ttf-mplus-1mn-bold ttf-mplus-1mn-light ttf-mplus-1mn-medium ttf-mplus-1mn-regular ttf-mplus-1mn-thin \
ttf-mplus-1p-black ttf-mplus-1p-bold ttf-mplus-1p-heavy ttf-mplus-1p-light ttf-mplus-1p-medium ttf-mplus-1p-regular ttf-mplus-1p-thin \
ttf-mplus-2c-black ttf-mplus-2c-bold ttf-mplus-2c-heavy ttf-mplus-2c-light ttf-mplus-2c-medium ttf-mplus-2c-regular ttf-mplus-2c-thin \
ttf-mplus-2m-bold ttf-mplus-2m-light ttf-mplus-2m-medium ttf-mplus-2m-regular ttf-mplus-2m-thin \
ttf-mplus-2p-black ttf-mplus-2p-bold ttf-mplus-2p-heavy ttf-mplus-2p-light ttf-mplus-2p-medium ttf-mplus-2p-regular ttf-mplus-2p-thin \
ttf-sazanami-gothic ttf-sazanami-mincho \
ttf-ubuntu-mono ttf-ubuntu-sans \
ttf-wqy-zenhei"

#
# Additional packages to be installed to the specific images
#
IMAGE_INSTALL_append_pn-core-image-sato = " \
${IMAGE_TTF_FONTS}"

ただし、このまま「bitbake core-image-sato」コマンドを実行すると、ttf-mplusのビルド時にエラーに遭遇します。これはttf-mplusのレシピの記述内容が不完全なために起きているエラーです。このエラーを解決するには、ttf-mplusのレシピに以下のような改造を加える必要があります。
require ttf.inc

SUMMARY = "MPlus font - TTF Edition"
HOMEPAGE = "http://dejavu.sourceforge.net/wiki/"
LICENSE = "${PN}"
LIC_FILES_CHKSUM = "file://LICENSE_E;md5=ac161e96eda00db9a3aec7870b5d9658 \
file://LICENSE_J;md5=a120ca8d7c8e4a475d5277c9aeb95221 \
"
PR = "r4"

SRC_URI = "http://osdn.dl.sourceforge.jp/mplus-fonts/6650/mplus-TESTFLIGHT-${PV}.tar.gz"
S = "${WORKDIR}/mplus-TESTFLIGHT-${PV}"

PACKAGESPLITFUNCS_prepend = "split_ttf_mplus_packages "

python split_ttf_mplus_packages() {
plugindir = d.expand('${datadir}/fonts/ttf-mplus/')
packages = do_split_packages(d, plugindir, '^(.*)\.ttf$', 'ttf-%s', 'TTF Font %s')
d.setVar('FONT_PACKAGES', ' '.join(packages))
}

do_install() {
install -d ${D}${datadir}/fonts/ttf-mplus
install -m 0644 *.ttf ${D}${datadir}/fonts/ttf-mplus/
}

SRC_URI[md5sum] = "d1400184b51b3871e8d2fca6c50e18ae"
SRC_URI[sha256sum] = "a20b9b9b03c2a6fb1e2137d29e8a6ce06406ba1e008906ea3c474dc048dc06a6"

TTF_FONTS = "\
ttf-mplus-1c-black ttf-mplus-1c-bold ttf-mplus-1c-heavy ttf-mplus-1c-light ttf-mplus-1c-medium ttf-mplus-1c-regular ttf-mplus-1c-thin \
ttf-mplus-1m-bold ttf-mplus-1m-light ttf-mplus-1m-medium ttf-mplus-1m-regular ttf-mplus-1m-thin \
ttf-mplus-1mn-bold ttf-mplus-1mn-light ttf-mplus-1mn-medium ttf-mplus-1mn-regular ttf-mplus-1mn-thin \
ttf-mplus-1p-black ttf-mplus-1p-bold ttf-mplus-1p-heavy ttf-mplus-1p-light ttf-mplus-1p-medium ttf-mplus-1p-regular ttf-mplus-1p-thin \
ttf-mplus-2c-black ttf-mplus-2c-bold ttf-mplus-2c-heavy ttf-mplus-2c-light ttf-mplus-2c-medium ttf-mplus-2c-regular ttf-mplus-2c-thin \
ttf-mplus-2m-bold ttf-mplus-2m-light ttf-mplus-2m-medium ttf-mplus-2m-regular ttf-mplus-2m-thin \
ttf-mplus-2p-black ttf-mplus-2p-bold ttf-mplus-2p-heavy ttf-mplus-2p-light ttf-mplus-2p-medium ttf-mplus-2p-regular ttf-mplus-2p-thin"

PACKAGES = "ttf-mplus ${TTF_FONTS}"

ALLOW_EMPTY_ttf-mplus = "1"

ここまでの変更が終わったら、あとは「bitbake core-image-sato」コマンドを実行すれば、上記の全TrueTypeフォントを追加したcore-image-satoイメージを生成できます。

このcore-image-satoイメージを起動すると、下のように、Sato GUIのDesktopウィンドウの表示フォントが変化していることに気づくでしょう(上に掲載したTrueTypeフォントを追加する前のDesktopウィンドウのスクリーンショットと比較してください)。
UBShot_20150125_230128-Adding_TTF-Yocto_Sato_Desktop-QEMUx86_64-1026x797
そして、Midoriを起動して日本語を含むページを開くと、日本語の文字が正常に表示されることが確認できるはずです。
UBShot_20150126_000156-Adding_TTF-Yocto_Sato_Desktop-QEMUx86_64-1026x797
なお、他のWebブラウザと同様に、Midoriでもデフォルトの表示フォントや文字エンコーディングを変更することができます。これらの設定を変更したい場合は、Midoriのページ・ウィンドウの右上の一番端に存在するToolsアイコンをクリックして[Preferences]というメニューを選択してください。
UBShot_20150126_000214-Adding_TTF-Yocto_Sato_Desktop-QEMUx86_64-1026x797
開いたウィンドウの[Fonts]タブを選ぶと、下のようなウィンドウに変わります。
UBShot_20150126_000237-Adding_TTF-Yocto_Sato_Desktop-QEMUx86_64-1026x797
Midoriのデフォルトの表示フォントと文字エンコーディングはこのウィンドウ内の項目を変更することで設定できます。同ウィンドウ内の[Proportional Font Family][Fixed-witdh Font Family]プルダウンメニューをクリックすると、選択可能なフォントの種類が増えていることが確認できます。
UBShot_20150126_000356-Adding_TTF-Yocto_Sato_Desktop-QEMUx86_64-1026x797
UBShot_20150126_000416-Adding_TTF-Yocto_Sato_Desktop-QEMUx86_64-1026x797
上側のスクリーンショットが[Proportional Font Family]プルダウンメニューに表示される項目で、下側が[Fixed-witdh Font Family]プルダウンメニューの項目です。

なお、インターネット経由で入手可能なフリーのTrueTypeフォントは他にもたくさん存在しており、私はこのようなフォントをMac OS Xで利用しています。Yocto LinuxのTrueTypeフォントのレシピを読むと、レシピ内に記述されているコードに一定のパターンが存在していて、それらに難しい部分は含まれていないように思えます。TrueTypeフォントのレシピを書くのは容易そうなので、そのうち他の日本語TrueTypeフォントをSato GUI環境へ組み込んでみようと思っています。この試みが成功したら、また記事として紹介するつもりです。

長くなってしまうので、Sato Mobile Desktopの日本語表示化に関する記事は2つに分けることにします。じつは、Sato GUI環境の日本語表示化を完全な形で実現するには、日本語のTrueTypeフォントを組み込むだけではダメで、他にもやらなくてはいけないことがあります。それはターゲットイメージに組み込まれるロケール情報のカスタマイズなのですが、その辺の説明は次の記事に書いていきます。


posted by とみやん at 10:06| Comment(0) | TrackBack(0) | Embedded Linux > Yocto Project

2015年01月16日

[Yocto] Sato Mobile DesktopへのMidoriブラウザの組込み

年末年始休暇もほとんど仕事関連の調査で潰してしまい、年が明けてからも多忙な日々が続いていましたが、本業の仕事もやっと終わりそうな状況になってきました。仕事だけにすべての時間を捧げる日々を過ごしていましたが、少し落ち着いてきたので、これからYocto Linux以外の研究テーマにも時間を割けるようになりそうです。とは言いながら、またしてもYocto Linuxの記事を書いてしまいます。他のネタも持ってはいるのですが、それらはまだ仕込中で、記事として公開できる状態まで練上がっていません。

ここのところハード&BSP系の情報やシステム寄りのパッケージの紹介などの所謂下周りの記事が続いたので、少し毛色を変えて、これからしばらくYocto LinuxのGUI環境のカスタマイズに関する記事を書こうと思います。組込み屋としては、デバイスドライバとかシステムの設定などをいじくり回す方が好きなのですが、GUIカスタマイズ、GUIアプリやWebサービスの導入方法や開発手法などの上周りの情報の方が需要が高いんじゃないでしょうか。Arduino、mbed、Rasberry Piなどのボードが流行っているのも、下周りをあまり弄らなくても、そこそこ高機能なシステムが構築できてしまうことが理由ではないかと思っています。Yocto Linuxの上周りの記事の第一段として、小ネタの情報になりますが、Sato Mobile Desktop環境へWebブラウザを組み込む方法について紹介しましょう。

Yocto Linuxの配布パッケージには、core-image-satoという名前のリファレンス的なイメージレシピが収納されています。いままでの記事にもスクリーンショットを掲載して紹介していますが、このcore-image-satoイメージレシピから生成できるのがYocto Linuxの標準GUI環境であるSato Mobile Desktopです。Sato Mobile Desktopはモバイル機器向けの軽量なGUI環境ですが、残念なことに、デフォルト状態ではcore-image-satoイメージにWebブラウザが組み込まれていません。しかし、WebブラウザのレシピはYocto Linuxの配布パッケージにちゃんと収納されています。Midoriという名前のWebブラウザがそれです。MidoriはレンダリングエンジンにWebKitを、ツールキットにGTK+2を使用している軽量なWebブラウザで、多くの組込みLinuxディストリビューションで採用されています。それではなぜデフォルト状態のcore-image-satoイメージにMidoriが組み込まれていないのかと言うと、これは想像になりますが、その理由はターゲットイメージのビルドに時間がかかってまうからだと思います。実際に作業をやってみて分かったのですが、core-image-satoイメージへMidoriを追加すると、クリーンビルドの時間がさらに1時間を伸びてしまいました(高性能なPCでも3時間以上、低性能なPCなら4〜6時間位かかるでしょう)。

core-image-satoレシピから生成されるイメージにMidoriを組み込む方法はすごく簡単です。以下のような変数定義をlocal.conf内に追加するだけです。
#
# Install the Midori web browser to Sato Desktop images. The WEB variable, which
# is defined in packagegroup-core-x11-sato.bb, is set to an empty value as default.
#
WEB = "midori"

たったこれだけで、core-image-satoイメージへMidoriを組み込むことができます。

Midoriを組み込むと、Sato GUI環境のDesktopウィンドウに下のようなアプリケーション・アイコンが追加されます。
UBShot_20150117_093041-Installing_Midori-Yocto_Sato_Desktop-1366x768
2つのアイコンが存在しますが、「Midori」の方が普通にWebブラウザを起動し、「Midori Private Browsing」の方はWebブラウザの起動後にURL履歴やCookie情報などを一切記録しません。この2つのアイコンをクリックした際のMidoriのスタートアップ画面を下に示します。
UBShot_20150117_093250-Installing_Midori-Yocto_Sato_Desktop-1366x768
UBShot_20150117_093317-Installing_Midori-Yocto_Sato_Desktop-1366x768
Midoriは組込みシステム向けの最低限の機能しか備えていないWebブラウザです。ChromeやSafariなどと比較すると、Midoriの操作性はとても良いとは言えません。レンダリング性能も低く、グラフィックや画像の多いページだと表示に結構時間がかかります。機能や性能が高いと、その分メモリやディスク容量を消費します。組込みシステムではメモリやディスクの容量に制限があるので、トレードオフの観点からするとこの辺は仕方がないことなのでしょう。まぁ、それでも普通にブラウジングはできます。

なお、上記のlocal.conf内に追加したWEBという変数は、packagegroup-core-x11-sato.bbというレシピファイルの中にそのデフォルト値が定義されています。その部分の抜粋を下に示します。
# pcmanfm doesn't work on mips
FILEMANAGER ?= "pcmanfm"
FILEMANAGER_mips ?= ""

WEB ?= ""
#WEB = "midori"

SUMMARY_${PN}-apps = "Sato desktop - applications"
RDEPENDS_${PN}-apps = "\
leafpad \
gaku \
x11vnc \
matchbox-terminal \
sato-screenshot \
${FILEMANAGER} \
${WEB} \
"

常にSato GUI環境にMidoriを入れておきたい場合は、上のWEB変数の設定定義を変更して、「WEB = "midori"」の方を有効にしておくと良いでしょう。その場合、local.conf側の定義は不要になります。

【2015/01/21 追記】

本記事に掲載したスクリーンショットは、XS36V4上で動いているYocto LinuxのSato Mobile Desktopから撮りました。

QEMUエミュレーション環境でもMidoriブラウザが動くのか興味があったので、試しにQEMU x86-64(64ビット版)ターゲット用にMidoriブラウザを組み込んだcore-image-satoイメージをビルドしてみました。下のスクリーンショットが、QEMU x86-64ターゲット上で動作しているSato GUIとMidoriブラウザの画面です。
UBShot_20150121_193732-Installing_Midori-Yocto_Sato_Desktop-QEMUx86_64-1026x797
UBShot_20150121_193812-Installing_Midori-Yocto_Sato_Desktop-QEMUx86_64-1026x797
試していませんが、QEMU x86(32ビット版)でもMidoriブラウザは問題なく動作するはずです。

ターゲット実機を持っていない人でも記事の内容を試せるので、Yocto LinuxのGUI環境カスタマイズに関する記事はQEMU x86-64をターゲットとして書いていきます。
posted by とみやん at 14:52| Comment(0) | TrackBack(0) | Embedded Linux > Yocto Project

2015年01月13日

[Yocto] XS36V4へのWi-Fi機能(RTL8188EEドライバ)追加

前記事に書いたとおり、Shuttle XS36V4でYocto Linuxを動かすことはトラブルに遭遇することもなくすんなりと成功してしまいました。Valley Island BSPに収納されているバイナリ・イメージと自分でビルドしたDE3815TYKHE用のイメージの2つを使いましたが、どちらでも特に問題なくXS36V4でYocto Linuxは動作しました。Valley Island BSPはデフォルト状態でRTL8168/8169/8111/8411ドライバが有効になっていたので、ドライバを組み込むことなくEthernetインターフェースも使えました。ただし、一つ大きな課題を見つけてしまいました。それは、Yocto LinuxがXS36V4の無線LANデバイスを認識していないことです。

前記事で使ったDE3815TYKHE用のcore-image-satoイメージは、カーネルレシピに主要な無線LANドライバをすべて組み込んた状態でビルドしたものです。〔2014/12/29の記事linux-yocto_3.10.bbappendを参照〕lspciコマンドの出力情報によって、XS36V4に搭載されている無線LANデバイスはRealtek RTL8188EEという物であることが判りました。しかし、dmesgコマンドのカーネル・ログを確認しても、RTL8188EE用ドライバはロードされていませんでした。Sato Mobile DesktopのGUI画面からconnman-gnomeを起動してみましが、下のとおり、やはりServicesリストに[Wireless Networks]というカテゴリ・エントリは存在していません。
UBShot_20150113_103340-YoctoLinux-Enabling_RTL8188EE_WLAN_Driver-1366x768
どうやらRTL8188EE用の無線LANドライバがカーネルへ組み込まれていないようです。

ググって調べてみると、カーネルソース・ツリーにRTL8188EE用ドライバは存在しており、これを有効にするにはCONFIG_RTL8188EEというコンフィグレーション設定項目を有効する必要があることが判りました。現状のカーネルのコンフィグレーション設定を確認すると、やはりこの項目は有効になっていませんでした。
# zcat /proc/config.gz | grep CONFIG_RTL8188EE
# CONFIG_RTL8188EE is not set

上記の情報に基いて、XS36V4のWi-Fi機能を利用可能にする作業を行ったので、その作業記録を本記事に書きます。

■ RTL8188EE無線LANドライバの組み込み


まずは、一時的にコンフィグレーション設定を変更して、カーネルへRTL8188EEドライバを組み込む作業を行いました。

bitbake linux-yocto -c menuconfig」コマンドによってカーネルのコンフィグレーション画面を開いて、以下のメニュー項目を有効にすれば、RTL8188EEドライバを組み込むことができます。〔2014/10/25の記事を参照〕
UBShot_20150113_115841-YoctoLinux-Enabling_RTL8188EE_WLAN_Driver-704x766
         Device Drivers  --->

[*] Nework device support --->

[*] Wireless LAN --->

<M> Realtek RTL8188EE Wireless Network Adapter

上の操作を行った後、以下のコマンドを実行して、RTL8188EEドライバを組み込んだcore-image-satoイメージを作成しました。
% bitbake linux-yocto -c compile -f
% bitbake linux-yocto -c deploy
% bitbake linux-yocto
% bitbake core-image-sato

core-image-satoのhddimgファイルからLive USBを作成して、このUSBメディアを使って、XS36V4でYocto Linuxを起動しました。そして、CONFIG_RTL8188EEが有効になっていることを確認しました。
# zcat /proc/config.gz | grep CONFIG_RTL8188EE
CONFIG_RTL8188EE=m

続いて、dmesgコマンドによってRTL8188EEドライバがロードされているかを確認しました。
# dmesg
.... ....
.... ....
.... ....
.... ....
[ 6.241182] cfg80211: Calling CRDA to update world regulatory domain
[ 6.375266] rtl8188ee 0000:01:00.0: enabling device (0000 -> 0003)
[ 6.383289] rtl8188ee: Using firmware rtlwifi/rtl8188efw.bin
[ 6.397905] ieee80211 phy0: Selected rate control algorithm 'rtl_rc'
[ 6.398161] rtlwifi: wireless switch is on
.... ....

connman-gnomeを起動してみると、Servicesリストにちゃんと[Wireless Networks]のエントリが追加されていました。
UBShot_20150113_123138-YoctoLinux-Enabling_RTL8188EE_WLAN_Driver-1366x768
Wi-Fiアクセスポイントへの接続を試してみると、こちらも問題なくできました。
UBShot_20150113_123405-YoctoLinux-Enabling_RTL8188EE_WLAN_Driver-1366x768

■ XS36V4用BSPの作成


上記のとおり、一時的にカーネルのコンフィグレーション設定を変更してRTL8188EEドライバを組み込めば、Yocto LinuxでXS36V4のWi-Fi機能を使えるようになることを確認できました。そこで、XS36V4用のBSPを作成して、この成果をそれに反映しました。

2014/10/25の記事にDE3815TYKHE用BSPの作成方法を書きましたが、これと同じ方法でXS36V4用のBSPを作成しました。今回作成したXS36V4 BSPのファイル構成を以下に示します。

  meta-xs36v4
|-- conf
| |-- machine
| | `-- xs36v4.conf
| `-- layer.conf
|-- recipes-bsp
| `-- formfactor
| |-- formfactor
| | `-- xs36v4
| | `-- machconfig
| `-- formfactor_0.0.bbappend
`-- recipes-kernel
`-- linux
|-- linux-yocto
| `-- add_driver-net_wlan_rtl8188ee.cfg
`-- linux-yocto_3.10.bbappend

また、以下にXS36V4 BSPのレイヤ定義ファイル、ターゲット定義ファイル、カーネルレシピの内容を示します。
#We have a conf and classes directory, add to BBPATH
BBPATH .= ":${LAYERDIR}"

# We have a recipes directory, add to BBFILES
BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
${LAYERDIR}/recipes-*/*/*.bbappend"

BBFILE_COLLECTIONS += "xs36v4"
BBFILE_PATTERN_xs36v4 := "^${LAYERDIR}/"
BBFILE_PRIORITY_xs36v4 = "6"

LAYERDEPENDS_xs36v4 = "intel"

LICENSE_PATH += "${LAYERDIR}/custom-licenses"

#@TYPE: Machine
#@NAME: Shuttle XS36V4

#@WEBTITLE: Intel Celeron J1900 Processor (XS36V4) 64-bit with Open Source Frame Buffer Graphics

#@DESCRIPTION: Machine configuration for XS36V4 64-bit systems, without Intel-proprietary graphics bits

PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
PREFERRED_VERSION_linux-yocto ?= "3.10%"

require conf/machine/include/intel-corei7-64-common.inc
require conf/machine/include/intel-common-pkgarch.inc
require conf/machine/include/meta-intel.inc

MACHINE_FEATURES += "pcbios efi"
MACHINE_FEATURES += "wifi"

MACHINE_EXTRA_RRECOMMENDS += "linux-firmware"

XSERVER ?= "${XSERVER_X86_BASE} \
${XSERVER_X86_EXT} \
${XSERVER_X86_FBDEV} \
${XSERVER_X86_I965} \
"

APPEND += "acpi_enforce_resources=lax video=efifb:off vga=0x318"

FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"

#############################
# MACHINE = xs36v4 #
#############################
COMPATIBLE_MACHINE_xs36v4 = "xs36v4"
KMACHINE_xs36v4 = "valleyisland"
KBRANCH_xs36v4 = "standard/base"
KERNEL_FEATURES_xs36v4 = " features/valleyisland-io/valleyisland-io.scc \
features/valleyisland-io/valleyisland-io-pci.scc \
features/wifi/wifi-all.scc"

LINUX_VERSION_xs36v4 = "3.10.59"
SRCREV_machine_xs36v4 = "747e1cbd12b15db8bc2ae86e2359c1b113f120d6"
SRCREV_meta_xs36v4 = "8f05306a8e6f5ee422d50c3317acce0cf9e6aada"
SRCREV_valleyisland-io_xs36v4 = "0992d01f5f382f6da60004ef87f67ebd3ca13732"

SRC_URI_xs36v4 = "git://git.yoctoproject.org/linux-yocto-3.10.git;protocol=git;nocheckout=1;branch=${KBRANCH},${KMETA},valleyisland-io-3.0;name=machine,meta,valleyisland-io"

SRC_URI_xs36v4 += "file://add_driver-net_wlan_rtl8188ee.cfg"

module_autoload_i2c-dev = "i2c-dev"

上のファイルで定義しているのは64ビット版ターゲットだけです。今回32ビット版ターゲットの定義は省略しました。XS36V4で32ビット版Yocto Linuxを動かすことはまずないだろうと思ったからです。DE3815TYKHEでも、32ビット版ターゲット用にYocto Linuxをビルドしたことはいままで一度もありません。

カーネルレシピlinux-yocto_3.10.bbappend内で参照しているコンフィグレーションフラグメントは、以下のような内容です。
++ .config	2015-01-12 15:55:39.777257022 +0900
CONFIG_RTL8188EE=m

このファイルは、カーネルのコンフィグレーション・メニュー画面で「Realtek RTL8188EE Wireless Network Adapter」の設定項目を有効にし、メニュー画面を終了した直後に「bitbake linux-yocto -c diffconfig」コマンドを実行することで作成しました。

上記のXS36V4用BSPを作成した後、このBSPを使ってcore-image-satoイメージをビルドし、XS36V4でYocto Linuxが起動することを確認しました。Wi-Fi機能も問題なく動作していました。

なお、Shuttle XS36V4にはXS35V4という姉妹モデルが存在しますが、この2つの機種のハード仕様は同一だと思われます。未確認ですが、今回作成したBSPはXS35V4でも使えるはずです。〔本記事に掲載したXS36V4 BSPを利用してXS35V4で動作確認を行った方がいれば、その結果を報告していただけると有難いです〕

【2015/01/15 追記】

本記事に掲載したXS36V4 BSPを使うと、RTL8188EEドライバと一緒に主要な無線LANドライバもすべてカーネルに組み込まれてしまいます。無線LANカードを換装したときに設定を変える必要がないので、これはこれで便利なのですが、ターゲットに搭載されていないデバイスのためのドライバが入っている状態になっています。組込みシステムではこういう状態は好ましくありません。

RTL8188EE用以外の無線LANドライバを削除したい場合は、カーネルレシピlinux-yocto_3.10.bbappendとコンフィグレーションフラグメントの内容を以下のように変更すると良いでしょう。
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"

#############################
# MACHINE = xs36v4 #
#############################
COMPATIBLE_MACHINE_xs36v4 = "xs36v4"
KMACHINE_xs36v4 = "valleyisland"
KBRANCH_xs36v4 = "standard/base"
KERNEL_FEATURES_xs36v4 = " features/valleyisland-io/valleyisland-io.scc \
features/valleyisland-io/valleyisland-io-pci.scc"

LINUX_VERSION_xs36v4 = "3.10.59"
SRCREV_machine_xs36v4 = "747e1cbd12b15db8bc2ae86e2359c1b113f120d6"
SRCREV_meta_xs36v4 = "8f05306a8e6f5ee422d50c3317acce0cf9e6aada"
SRCREV_valleyisland-io_xs36v4 = "0992d01f5f382f6da60004ef87f67ebd3ca13732"

SRC_URI_xs36v4 = "git://git.yoctoproject.org/linux-yocto-3.10.git;protocol=git;nocheckout=1;branch=${KBRANCH},${KMETA},valleyisland-io-3.0;name=machine,meta,valleyisland-io"

SRC_URI_xs36v4 += "file://add_config-wifi_rtl8188ee.cfg"

module_autoload_i2c-dev = "i2c-dev"

# Common Wifi Infrastructure
CONFIG_NET=y
CONFIG_WIRELESS=y
CONFIG_WIRELESS_EXT=y
CONFIG_NETDEVICES=y
CONFIG_WLAN=y

CONFIG_CFG80211=m
CONFIG_CFG80211_DEFAULT_PS=y
CONFIG_CFG80211_WEXT=y

CONFIG_MAC80211=m
CONFIG_MAC80211_RC_PID=y
CONFIG_MAC80211_RC_MINSTREL=y
CONFIG_MAC80211_RC_MINSTREL_HT=y
CONFIG_MAC80211_RC_DEFAULT_MINSTREL=y
CONFIG_MAC80211_RC_DEFAULT="minstrel_ht"
CONFIG_MAC80211_MESH=y
CONFIG_MAC80211_LEDS=y

CONFIG_AVERAGE=y

# Realtek RTL8188EE Wireless Driver
CONFIG_RTLWIFI=m
CONFIG_RTL8188EE=m

上のカーネルレシピでは、「KERNEL_FEATURES_xs36v4 = " ... features/wifi/wifi-all.scc"」という設定記述を削除しています。上のコンフィグレーションフラグメントで定義しているのは、このファイル内のカーネル・コンフィグレーション設定項目の一部です。
posted by とみやん at 10:59| Comment(0) | TrackBack(0) | Embedded Linux > Yocto Project

2015年01月11日

[Yocto] Shuttle XS36V4でYocto Linuxを動かす

皆様、新年明けましておめでとうございます。年が明けてもう10日も経ってしまったので、遅らせばながらの挨拶ですね。皆様どのように正月を過ごされましたか。

私の方は年末年始もずっと研究活動の調べ事をやったり、その内容をブログ記事に書いたりして過ごしていました。完全休養日は大晦日と正月一日の2日間だけで、その他の日はずっと仕事をしていたような感じです。おかげで、穏やかな正月という訳にはいかず、ぜんぜん休んだ気がしません。一応本業の仕事は休みだったですが、どうしても本業の仕事に関連した技術的な調査をやらざるをえない状況だったので、結局自主的に年末年始休暇をほぼ全部つぶして研究活動の作業をやっていました。

さて、ずっとYocto Projectの記事が続いていますが、またしても同研究テーマに関連した記事を書きます。

Yocto Linux用の新しいターゲット機を入手しました。Shuttle XS36V4という奴で、DE3815TYHKEと同様に一般向けのベアボーンPCです。
ANIMG_20150110_153042-Shuttle_XS36V4-Unboxing_ProductViews.jpg
ANIMG_20150110_153710-Shuttle_XS36V4-Unboxing_ProductViews.jpg
ANIMG_20150110_154337-Shuttle_XS36V4-Unboxing_ProductViews.jpg
ANIMG_20150110_154846-Shuttle_XS36V4-Unboxing_ProductViews.jpg
ANIMG_20150110_155413-Shuttle_XS36V4-Unboxing_ProductViews.jpg
この機種に搭載されているプロセッサはIntel J1900という奴です。J1750/1800/1900(Bay Trail-D)はE38xx(Bay Trail-I)よりは若干消費電力が高いですが、それでもTDPは10Wと十分に優れた性能です。J1900搭載PCを使ってメディア・サーバーを一台組みたいと思っていたのですが、結局組込みLinuxのターゲットとして使うことを優先して、このXS36V4を選択してしまいました。J1800/1900を搭載したベアボーンPCやMini-ITXボードは結構多くの種類の製品が販売されています。その中からXS36V4を選んだのは、この機種に外部シリアル・コネクタが搭載されていたからです(この機種にはXS35V4という姉妹モデルもあり、そちらはシリアルは無くCD/DVDドライブを搭載しています)。最近のPCには珍しく、XS36V4にはシリアルが2個も搭載されています。組込みLinuxのターゲット機はモニタやタッチパネルなしで運用することが良くあります。こういう機器でも大抵はシリアルだけは活かしておいて、メンテナンス用に使ったりします。マイコン搭載機器でもそうですが、組込み用ターゲットではシリアルはいまだに必須のインターフェースです。これはマイコンが登場した頃からずっと続いており、これからも変わらないでしょう。

■ XS36V4の組み立て


XS36V4に部品を追加してPCとして組み上げたので、その作業の様子を紹介します。DE3815TYKHEと同様にXS36V4のCPUもオンボードの直付けです。したがって、追加部品として必要なのはメモリとSATAディスクだけです。以下の2つ部品を用意しました。
  • Transcend PC3L-12800(DDR3L-1600)1.35V TS1GSK64W6H
  • Intel 320 Series SSD 120GB

ANIMG_20150110_160123-Shuttle_XS36V4-AddtionalParts_Building.jpg
ANIMG_20150110_160159-Shuttle_XS36V4-AddtionalParts_Building.jpg
SO-DIMMメモリはXS36V4と一緒にAmazonから購入し、SSDの方はオークション落札で中古品を入手しました。メモリは4GBと8GBのどちらにするか迷いましたが、今回は奮発して8GBを選びました。これは後日4GBに差し替えるかもしれません。Windowsならメモリは8GBないと苦しいですが、Linuxなら4GBもあれば十分だからです。このXS36V4でメディア・サーバーを組み上げる場合も、OSはUbuntuかCentOSを使って構築するつもりです。

部品を組み込むために、まずはXS36V4本体のケースを開けてみました。XS36V4は両面のケース・カバーがそれぞれ開くようになっています。
ANIMG_20150110_160952-Shuttle_XS36V4-AddtionalParts_Building.jpg

マザーボードが見える方の面の真中辺りにDIMMスロットが在ります。同面の右上部にはMini-PCIeスロットが在りますが、ここには無線LANカードが取り付け済みでした。この無線LANカードはRealtek製のようです。Realtekの無線LANチップはあまりの評判が良くないので、近いうちにこれはIntel製の無線LANカードに取り替えようと思っています。

メモリとSSDの取り付け作業はいずれも難しくありませんでした。メモリはDIMMスロットに挿し込むだけです。
ANIMG_20150110_161206-Shuttle_XS36V4-AddtionalParts_Building.jpg
SSDの方は専用の金具にネジ止めしてから、裏面の所定の場所に金具ごとネジで固定するだけです。
ANIMG_20150110_161408-Shuttle_XS36V4-AddtionalParts_Building.jpg
ANIMG_20150110_162349-Shuttle_XS36V4-AddtionalParts_Building.jpg
ANIMG_20150110_163508-Shuttle_XS36V4-AddtionalParts_Building.jpg
メモリとSSDを取り付けたら、両面のカバーを閉めれば組み立て作業は終わりです。XS36V4本体のカバーの開け方だけちょっとコツが要りますが、その辺の情報は製品に同梱されている組立説明書に書いてあります。一度でもベアボーンPCを組み立てたことのある人なら誰でもできるほど容易な作業だと思いますが、あらかじめ組立説明書は読んでおいた方が良いでしょう。

組み立て作業が終わったので、モニタ、キーボード、マウスを接続して、さっそくXS36V4の電源を入れてみました。すると、下のようなEFI Shellの起動画面がモニタに表示されました。
ANIMG_20150111_164357-Shuttle_XS36V4-Booting_EFIShell_Screen.jpg
XS36V4に搭載されているBIOSはAMI製のUEFIベースの物です。SSDにOSが入っていない状態なので、EFI Shellが起動したようです。「exit」というコマンドをタイプすると、EFI Shellから抜けて、BIOSの画面へ戻ることができます。
ANIMG_20150111_164532-Shuttle_XS36V4_Booting_AMIBIOS_Screen..jpg
一部のUEFI BIOSはEFI Shellを起動しないように設定できるですが、XS36V4のBIOSはできないようです。EFI Shellからできることも色々あるのですが、一般人がEFI Shellを使う必要性はまずないでしよう。一度HDD/SSDへOSをインストールしてしまうと、EFI Shellは邪魔なだけです。BIOSのデフォルト設定でEFI Shellは起動しないようになっている方が、一般人にとっては親切ではないかと思います。

■ XS36V4によるYocto Linuxの動作確認


XS36V4を入手した本来の目的は、こいつでメディア・サーバーを組み立てることだったのですが、本業の仕事が忙しすぎて、近々にはその作業やる時間を取れそうもありません。他にも優先してやりたい研究テーマもあるので、メディア・サーバーの構築はずっと先になりそうです。せっかく入手したのに全然使わないのはもったいないので、取りあえず、XS36V4でYocto Linuxを動かしてみました。

Intelのサイトに掲載されているJ1800/1900とE38xxのプロセッサ仕様情報を比較して、この2つは類似性の高いコアではないかと思っていました。そのため、Valley Island BSPからビルドしたイメージを使えば、多分XS36V4でもそのままYocto Linuxが動くじゃないかと予測していました。そこで、最初にValley Island BSPに収納されているhddimgファイルからLive USBを作成して、そのUSBメディアからYocto Linuxを起動してみました。Valley Island(Intel E38xx)用のLive USBメディアは以下のコマンドによって作成できます。
% cd ~/Yocto
% cd poky-daisy-11.0.2
% cd meta-intel/binary
% umount /dev/sdc
% sudo dd if=core-image-sato-valleyisland-64.hddimg of=/dev/sdc
% sync

上記の方法によって、特に問題なくXS36V4でYocto Linuxが起動して、Sato Mobile Desktopの画面がモニタに表示されました(予想どおりだったとは言え、ちょっと拍子抜けです)。下の写真がその様子です。
ANIMG_20150111_160012-Shuttle_XS36V4-Running_YoctoLinux.jpg
ちなみに、上の写真に写っている液晶モニタはGechic On-Lap1302という物です。このモニタの特長はUSBから電源が取れることで、PCのUSBポートから電源を供給できます。最近このメーカーの製品の再整備品が秋葉原のPCショップや通販ショップなどで広く出回っています。去年の年末に秋葉原に行ったときに、TWOTOP FreeT(BUY MORE秋葉原本店)で特価販売されているのを見つけて一台買ってしまいました。

Valley Island BSPに収納されているイメージによってYocto Linuxが正常に起動することが確認できたので、次に自分でビルドしたイメージを使ってみました。2014/12/29の記事でクリーンビルドしたDE3815TYHKE用のcore-image-satoイメージからLive USBを作成して、そのUSBメディアを使って、XS36V4の内蔵SATAへYocto Linuxをインストールしました。そして、XS36V4の内蔵SATAからYocto Linuxを起動してみましたが、こちらも特に問題なく起動できました。J1900はE38xxと同じBay Trail系コアのx86プロセッサでなので、これは当然の結果ですが、どうやらXS36V4でYocto Linuxを使うのは問題なくできるようです。

予想どおりの結果だったので一安心ですが、ここで組込み屋として気になるのは、やはりXS36V4のハードウェアの詳細仕様です。そこで、いくつかのコマンドを使ってXS36V4のハード情報を取得してみました。まずは、プロセッサ情報の確認から始めました。
# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 55
model name : Intel(R) Celeron(R) CPU J1900 @ 1.99GHz
stepping : 3
microcode : 0x320
cpu MHz : 1328.000
cache size : 1024 KB
physical id : 0
siblings : 4
core id : 0
cpu cores : 4
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp
lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm
sse4_1 sse4_2 movbe popcnt tsc_deadline_timer rdrand lahf_lm 3dnowprefetch ida arat epb dtherm tpr_shadow vnmi flexpriority ept vpid tsc_adjust smep erms
bogomips : 4000.16
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 55
model name : Intel(R) Celeron(R) CPU J1900 @ 1.99GHz
stepping : 3
microcode : 0x320
cpu MHz : 1328.000
cache size : 1024 KB
physical id : 0
siblings : 4
core id : 1
cpu cores : 4
apicid : 2
initial apicid : 2
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp
lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm
sse4_1 sse4_2 movbe popcnt tsc_deadline_timer rdrand lahf_lm 3dnowprefetch ida arat epb dtherm tpr_shadow vnmi flexpriority ept vpid tsc_adjust smep erms
bogomips : 4000.16
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

processor : 2
vendor_id : GenuineIntel
cpu family : 6
model : 55
model name : Intel(R) Celeron(R) CPU J1900 @ 1.99GHz
stepping : 3
microcode : 0x320
cpu MHz : 1328.000
cache size : 1024 KB
physical id : 0
siblings : 4
core id : 2
cpu cores : 4
apicid : 4
initial apicid : 4
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp
lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm
sse4_1 sse4_2 movbe popcnt tsc_deadline_timer rdrand lahf_lm 3dnowprefetch ida arat epb dtherm tpr_shadow vnmi flexpriority ept vpid tsc_adjust smep erms
bogomips : 4000.16
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

processor : 3
vendor_id : GenuineIntel
cpu family : 6
model : 55
model name : Intel(R) Celeron(R) CPU J1900 @ 1.99GHz
stepping : 3
microcode : 0x320
cpu MHz : 1328.000
cache size : 1024 KB
physical id : 0
siblings : 4
core id : 3
cpu cores : 4
apicid : 6
initial apicid : 6
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp
lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm
sse4_1 sse4_2 movbe popcnt tsc_deadline_timer rdrand lahf_lm 3dnowprefetch ida arat epb dtherm tpr_shadow vnmi flexpriority ept vpid tsc_adjust smep erms
bogomips : 4000.16
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:


プロセッサ情報が4つも表示されるのは壮観ですね。J1900が4コアのプロセッサであるメリットは、これからXS36V4を使っていくうちにきっと実感できるでしょう。

最近AES-NIの性能評価記事を続けて書いているので、じつは、一番気になっていたのはJ1900にAES-NIが搭載されているかどうかでした。上の/proc/cpuinfoの「flags」情報の中に「aes」の文字列は存在していません。IntelのJ1900のプロセッサ仕様情報にも「AES-NI: No」と掲載されているので、やはりJ1900はAES-NIを内蔵していないようです。AES-NIが内蔵されていることを期待していたので、これはかなり残念です。本件に関連してIntelのプロセッサ仕様情報を調べまわったのですが、Bay Trail系プロセッサの中でAES-NIが搭載されているのはZ374x/377xとE38xxだけのようです。

cpuinfo情報に続いて、lspciコマンドを使ってPCI-Eの情報を取得してみました。
# lspci
00:00.0 Host bridge: Intel Corporation ValleyView SSA-CUnit (rev 0c)
00:02.0 VGA compatible controller: Intel Corporation ValleyView Gen7 (rev 0c)
00:13.0 SATA controller: Intel Corporation ValleyView 6-Port SATA AHCI Controller (rev 0c)
00:14.0 USB controller: Intel Corporation ValleyView USB xHCI Host Controller (rev 0c)
00:1a.0 Encryption controller: Intel Corporation ValleyView SEC (rev 0c)
00:1b.0 Audio device: Intel Corporation ValleyView High Definition Audio Controller (rev 0c)
00:1c.0 PCI bridge: Intel Corporation ValleyView PCI Express Root Port (rev 0c)
00:1c.1 PCI bridge: Intel Corporation ValleyView PCI Express Root Port (rev 0c)
00:1c.2 PCI bridge: Intel Corporation ValleyView PCI Express Root Port (rev 0c)
00:1c.3 PCI bridge: Intel Corporation ValleyView PCI Express Root Port (rev 0c)
00:1f.0 ISA bridge: Intel Corporation ValleyView Power Control Unit (rev 0c)
00:1f.3 SMBus: Intel Corporation ValleyView SMBus Controller (rev 0c)
01:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8188EE Wireless Network Adapter (rev 01)
02:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. Device 5289 (rev 01)
02:00.2 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0a)

上のlspciコマンドの出力情報から、Ethernetと無線LANデバイスはいずれもRealtek製であることが判ります。

Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. Device 5289 (rev 01)」というのは一体何なのか気になったので、ググって調べてみました。どうやらこれはRealtek製のCard Reader Controllerのようです。XS36V4の前面にSDカード・スロットが搭載されているので、これを制御しているデバイスなのでしょう。このコントローラ用のドライバも存在しているようなので、そのうちYocto Linuxに組み込んでみようと思っています。

続いて、dmesgコマンドを実行しました。長くなりますが、同コマンドの全出力情報を以下に示します(Linux関連の仕事をしている人にとって、こういう情報が役に立つこともあります)。
# dmesg
[ 0.000000] Initializing cgroup subsys cpuset
[ 0.000000] Initializing cgroup subsys cpu
[ 0.000000] Initializing cgroup subsys cpuacct
[ 0.000000] Linux version 3.10.59-ltsi-yocto-standard (yuhri@hestia-vm1) (gcc version 4.8.2 (GCC) ) #1 SMP PREEMPT Sun Jan 11 13:43:17 JST 2015
[ 0.000000] Command line: BOOT_IMAGE=/vmlinuz root=/dev/sda2 rw quiet acpi_enforce_resources=lax video=efifb:off vga=0x318
[ 0.000000] e820: BIOS-provided physical RAM map:
[ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000008efff] usable
[ 0.000000] BIOS-e820: [mem 0x000000000008f000-0x000000000008ffff] ACPI NVS
[ 0.000000] BIOS-e820: [mem 0x0000000000090000-0x000000000009ffff] usable
[ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000001effffff] usable
[ 0.000000] BIOS-e820: [mem 0x000000001f000000-0x00000000200fffff] reserved
[ 0.000000] BIOS-e820: [mem 0x0000000020100000-0x00000000b711bfff] usable
[ 0.000000] BIOS-e820: [mem 0x00000000b711c000-0x00000000b714bfff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000b714c000-0x00000000b715bfff] ACPI data
[ 0.000000] BIOS-e820: [mem 0x00000000b715c000-0x00000000b78e2fff] ACPI NVS
[ 0.000000] BIOS-e820: [mem 0x00000000b78e3000-0x00000000b7bb2fff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000b7bb3000-0x00000000b7bb3fff] usable
[ 0.000000] BIOS-e820: [mem 0x00000000b7bb4000-0x00000000b7bf5fff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000b7bf6000-0x00000000b7d64fff] usable
[ 0.000000] BIOS-e820: [mem 0x00000000b7d65000-0x00000000b7ff9fff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000b7ffa000-0x00000000b7ffffff] usable
[ 0.000000] BIOS-e820: [mem 0x00000000e00f8000-0x00000000e00f8fff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000fed01000-0x00000000fed01fff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000ffb00000-0x00000000ffffffff] reserved
[ 0.000000] BIOS-e820: [mem 0x0000000100000000-0x000000023fffffff] usable
[ 0.000000] NX (Execute Disable) protection: active
[ 0.000000] efi: EFI v2.31 by American Megatrends
[ 0.000000] efi: ACPI=0xb7153000 ACPI 2.0=0xb7153000 SMBIOS=0xf04d0 MPS=0xfd4c0
[ 0.000000] efi: mem00: type=3, attr=0xf, range=[0x0000000000000000-0x0000000000008000) (0MB)
[ 0.000000] efi: mem01: type=7, attr=0xf, range=[0x0000000000008000-0x000000000002f000) (0MB)
[ 0.000000] efi: mem02: type=3, attr=0xf, range=[0x000000000002f000-0x000000000008f000) (0MB)
[ 0.000000] efi: mem03: type=10, attr=0xf, range=[0x000000000008f000-0x0000000000090000) (0MB)
[ 0.000000] efi: mem04: type=7, attr=0xf, range=[0x0000000000090000-0x000000000009f000) (0MB)
[ 0.000000] efi: mem05: type=4, attr=0xf, range=[0x000000000009f000-0x00000000000a0000) (0MB)
[ 0.000000] efi: mem06: type=2, attr=0xf, range=[0x0000000000100000-0x0000000001310000) (18MB)
[ 0.000000] efi: mem07: type=7, attr=0xf, range=[0x0000000001310000-0x0000000002000000) (12MB)
[ 0.000000] efi: mem08: type=2, attr=0xf, range=[0x0000000002000000-0x0000000003210000) (18MB)
[ 0.000000] efi: mem09: type=7, attr=0xf, range=[0x0000000003210000-0x000000001f000000) (445MB)
[ 0.000000] efi: mem10: type=0, attr=0xf, range=[0x000000001f000000-0x0000000020100000) (17MB)
[ 0.000000] efi: mem11: type=7, attr=0xf, range=[0x0000000020100000-0x000000006e11b000) (1248MB)
[ 0.000000] efi: mem12: type=2, attr=0xf, range=[0x000000006e11b000-0x0000000098000000) (670MB)
[ 0.000000] efi: mem13: type=4, attr=0xf, range=[0x0000000098000000-0x0000000098020000) (0MB)
[ 0.000000] efi: mem14: type=7, attr=0xf, range=[0x0000000098020000-0x00000000a8a58000) (266MB)
[ 0.000000] efi: mem15: type=1, attr=0xf, range=[0x00000000a8a58000-0x00000000a8ae6000) (0MB)
[ 0.000000] efi: mem16: type=4, attr=0xf, range=[0x00000000a8ae6000-0x00000000b6b1c000) (224MB)
[ 0.000000] efi: mem17: type=7, attr=0xf, range=[0x00000000b6b1c000-0x00000000b6e76000) (3MB)
[ 0.000000] efi: mem18: type=2, attr=0xf, range=[0x00000000b6e76000-0x00000000b6e7f000) (0MB)
[ 0.000000] efi: mem19: type=3, attr=0xf, range=[0x00000000b6e7f000-0x00000000b711c000) (2MB)
[ 0.000000] efi: mem20: type=0, attr=0xf, range=[0x00000000b711c000-0x00000000b714c000) (0MB)
[ 0.000000] efi: mem21: type=9, attr=0xf, range=[0x00000000b714c000-0x00000000b715c000) (0MB)
[ 0.000000] efi: mem22: type=10, attr=0xf, range=[0x00000000b715c000-0x00000000b78e3000) (7MB)
[ 0.000000] efi: mem23: type=6, attr=0x800000000000000f, range=[0x00000000b78e3000-0x00000000b7b68000) (2MB)
[ 0.000000] efi: mem24: type=5, attr=0x800000000000000f, range=[0x00000000b7b68000-0x00000000b7bb3000) (0MB)
[ 0.000000] efi: mem25: type=4, attr=0xf, range=[0x00000000b7bb3000-0x00000000b7bb4000) (0MB)
[ 0.000000] efi: mem26: type=6, attr=0x800000000000000f, range=[0x00000000b7bb4000-0x00000000b7bf6000) (0MB)
[ 0.000000] efi: mem27: type=4, attr=0xf, range=[0x00000000b7bf6000-0x00000000b7d65000) (1MB)
[ 0.000000] efi: mem28: type=6, attr=0x800000000000000f, range=[0x00000000b7d65000-0x00000000b7ffa000) (2MB)
[ 0.000000] efi: mem29: type=4, attr=0xf, range=[0x00000000b7ffa000-0x00000000b8000000) (0MB)
[ 0.000000] efi: mem30: type=7, attr=0xf, range=[0x0000000100000000-0x0000000240000000) (5120MB)
[ 0.000000] efi: mem31: type=11, attr=0x8000000000000000, range=[0x00000000e00f8000-0x00000000e00f9000) (0MB)
[ 0.000000] efi: mem32: type=11, attr=0x8000000000000000, range=[0x00000000fed01000-0x00000000fed02000) (0MB)
[ 0.000000] efi: mem33: type=11, attr=0x8000000000000000, range=[0x00000000ffb00000-0x0000000100000000) (5MB)
[ 0.000000] SMBIOS 2.8 present.
[ 0.000000] DMI: Shuttle Inc. XS36V4/FS36V4, BIOS 1.10 x64 04/18/2014
[ 0.000000] e820: update [mem 0x00000000-0x00000fff] usable ==> reserved
[ 0.000000] e820: remove [mem 0x000a0000-0x000fffff] usable
[ 0.000000] No AGP bridge found
[ 0.000000] e820: last_pfn = 0x240000 max_arch_pfn = 0x400000000
[ 0.000000] MTRR default type: uncachable
[ 0.000000] MTRR fixed ranges enabled:
[ 0.000000] 00000-9FFFF write-back
[ 0.000000] A0000-BFFFF uncachable
[ 0.000000] C0000-E7FFF write-through
[ 0.000000] E8000-FFFFF write-protect
[ 0.000000] MTRR variable ranges enabled:
[ 0.000000] 0 base 000000000 mask F80000000 write-back
[ 0.000000] 1 base 080000000 mask FC0000000 write-back
[ 0.000000] 2 base 0B8000000 mask FF8000000 uncachable
[ 0.000000] 3 base 100000000 mask F00000000 write-back
[ 0.000000] 4 base 200000000 mask F00000000 write-back
[ 0.000000] 5 disabled
[ 0.000000] 6 disabled
[ 0.000000] 7 disabled
[ 0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
[ 0.000000] e820: update [mem 0xb8000000-0xffffffff] usable ==> reserved
[ 0.000000] e820: last_pfn = 0xb8000 max_arch_pfn = 0x400000000
[ 0.000000] found SMP MP-table at [mem 0x000fd6c0-0x000fd6cf] mapped at [ffff8800000fd6c0]
[ 0.000000] Scanning 1 areas for low memory corruption
[ 0.000000] Base memory trampoline at [ffff880000087000] 87000 size 24576
[ 0.000000] init_memory_mapping: [mem 0x00000000-0x000fffff]
[ 0.000000] [mem 0x00000000-0x000fffff] page 4k
[ 0.000000] BRK [0x02f02000, 0x02f02fff] PGTABLE
[ 0.000000] BRK [0x02f03000, 0x02f03fff] PGTABLE
[ 0.000000] BRK [0x02f04000, 0x02f04fff] PGTABLE
[ 0.000000] init_memory_mapping: [mem 0x23fe00000-0x23fffffff]
[ 0.000000] [mem 0x23fe00000-0x23fffffff] page 2M
[ 0.000000] BRK [0x02f05000, 0x02f05fff] PGTABLE
[ 0.000000] init_memory_mapping: [mem 0x23c000000-0x23fdfffff]
[ 0.000000] [mem 0x23c000000-0x23fdfffff] page 2M
[ 0.000000] init_memory_mapping: [mem 0x200000000-0x23bffffff]
[ 0.000000] [mem 0x200000000-0x23bffffff] page 2M
[ 0.000000] init_memory_mapping: [mem 0x00100000-0x1effffff]
[ 0.000000] [mem 0x00100000-0x001fffff] page 4k
[ 0.000000] [mem 0x00200000-0x1effffff] page 2M
[ 0.000000] init_memory_mapping: [mem 0x20100000-0xb711bfff]
[ 0.000000] [mem 0x20100000-0x201fffff] page 4k
[ 0.000000] [mem 0x20200000-0xb6ffffff] page 2M
[ 0.000000] [mem 0xb7000000-0xb711bfff] page 4k
[ 0.000000] BRK [0x02f06000, 0x02f06fff] PGTABLE
[ 0.000000] BRK [0x02f07000, 0x02f07fff] PGTABLE
[ 0.000000] init_memory_mapping: [mem 0xb7bb3000-0xb7bb3fff]
[ 0.000000] [mem 0xb7bb3000-0xb7bb3fff] page 4k
[ 0.000000] init_memory_mapping: [mem 0xb7bf6000-0xb7d64fff]
[ 0.000000] [mem 0xb7bf6000-0xb7d64fff] page 4k
[ 0.000000] init_memory_mapping: [mem 0xb7ffa000-0xb7ffffff]
[ 0.000000] [mem 0xb7ffa000-0xb7ffffff] page 4k
[ 0.000000] init_memory_mapping: [mem 0x100000000-0x1ffffffff]
[ 0.000000] [mem 0x100000000-0x1ffffffff] page 2M
[ 0.000000] ACPI: RSDP 00000000b7153000 00024 (v02 Shuttl)
[ 0.000000] ACPI: XSDT 00000000b7153080 0007C (v01 Shuttl Shuttle 01072009 AMI 00010013)
[ 0.000000] ACPI: FACP 00000000b715a708 0010C (v05 Shuttl Shuttle 01072009 AMI 00010013)
[ 0.000000] ACPI: DSDT 00000000b7153188 0757F (v02 XS36V4 XS36V400 01072009 INTL 20120913)
[ 0.000000] ACPI: FACS 00000000b78e2f80 00040
[ 0.000000] ACPI: APIC 00000000b715a818 00084 (v03 Shuttl Shuttle 01072009 AMI 00010013)
[ 0.000000] ACPI: FPDT 00000000b715a8a0 00044 (v01 Shuttl Shuttle 01072009 AMI 00010013)
[ 0.000000] ACPI: MCFG 00000000b715a8e8 0003C (v01 Shuttl Shuttle 01072009 MSFT 00000097)
[ 0.000000] ACPI: LPIT 00000000b715a928 00104 (v01 Shuttl Shuttle 00000003 VLV2 0100000D)
[ 0.000000] ACPI: SLIC 00000000b715aa30 00176 (v01 Shuttl Shuttle 01072009 AMI 00010013)
[ 0.000000] ACPI: HPET 00000000b715aba8 00038 (v01 Shuttl Shuttle 01072009 AMI. 00000005)
[ 0.000000] ACPI: SSDT 00000000b715abe0 00763 (v01 PmRef CpuPm 00003000 INTL 20061109)
[ 0.000000] ACPI: SSDT 00000000b715b348 00290 (v01 PmRef Cpu0Tst 00003000 INTL 20061109)
[ 0.000000] ACPI: SSDT 00000000b715b5d8 0017A (v01 PmRef ApTst 00003000 INTL 20061109)
[ 0.000000] ACPI: UEFI 00000000b715b758 00042 (v01 Shuttl Shuttle 00000000 00000000)
[ 0.000000] ACPI: Local APIC address 0xfee00000
[ 0.000000] [ffffea0000000000-ffffea0008ffffff] PMD -> [ffff880237800000-ffff88023f5fffff] on node 0
[ 0.000000] Zone ranges:
[ 0.000000] DMA [mem 0x00001000-0x00ffffff]
[ 0.000000] DMA32 [mem 0x01000000-0xffffffff]
[ 0.000000] Normal [mem 0x100000000-0x23fffffff]
[ 0.000000] Movable zone start for each node
[ 0.000000] Early memory node ranges
[ 0.000000] node 0: [mem 0x00001000-0x0008efff]
[ 0.000000] node 0: [mem 0x00090000-0x0009ffff]
[ 0.000000] node 0: [mem 0x00100000-0x1effffff]
[ 0.000000] node 0: [mem 0x20100000-0xb711bfff]
[ 0.000000] node 0: [mem 0xb7bb3000-0xb7bb3fff]
[ 0.000000] node 0: [mem 0xb7bf6000-0xb7d64fff]
[ 0.000000] node 0: [mem 0xb7ffa000-0xb7ffffff]
[ 0.000000] node 0: [mem 0x100000000-0x23fffffff]
[ 0.000000] On node 0 totalpages: 2056496
[ 0.000000] DMA zone: 64 pages used for memmap
[ 0.000000] DMA zone: 40 pages reserved
[ 0.000000] DMA zone: 3998 pages, LIFO batch:0
[ 0.000000] DMA32 zone: 11591 pages used for memmap
[ 0.000000] DMA32 zone: 741778 pages, LIFO batch:31
[ 0.000000] Normal zone: 20480 pages used for memmap
[ 0.000000] Normal zone: 1310720 pages, LIFO batch:31
[ 0.000000] ACPI: PM-Timer IO Port: 0x408
[ 0.000000] ACPI: Local APIC address 0xfee00000
[ 0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x04] enabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x06] enabled)
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x01] dfl dfl lint[0x0])
[ 0.000000] ACPI: NMI not connected to LINT 1!
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x02] dfl dfl lint[0x0])
[ 0.000000] ACPI: NMI not connected to LINT 1!
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x03] dfl dfl lint[0x0])
[ 0.000000] ACPI: NMI not connected to LINT 1!
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x04] dfl dfl lint[0x0])
[ 0.000000] ACPI: NMI not connected to LINT 1!
[ 0.000000] ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])
[ 0.000000] IOAPIC[0]: apic_id 1, version 32, address 0xfec00000, GSI 0-86
[ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[ 0.000000] ACPI: IRQ0 used by override.
[ 0.000000] ACPI: IRQ2 used by override.
[ 0.000000] ACPI: IRQ9 used by override.
[ 0.000000] Using ACPI (MADT) for SMP configuration information
[ 0.000000] ACPI: HPET id: 0x8086a201 base: 0xfed00000
[ 0.000000] smpboot: Allowing 4 CPUs, 0 hotplug CPUs
[ 0.000000] nr_irqs_gsi: 103
[ 0.000000] e820: [mem 0xb8000000-0xe00f7fff] available for PCI devices
[ 0.000000] setup_percpu: NR_CPUS:64 nr_cpumask_bits:64 nr_cpu_ids:4 nr_node_ids:1
[ 0.000000] PERCPU: Embedded 27 pages/cpu @ffff88023fc00000 s80192 r8192 d22208 u524288
[ 0.000000] pcpu-alloc: s80192 r8192 d22208 u524288 alloc=1*2097152
[ 0.000000] pcpu-alloc: [0] 0 1 2 3
[ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 2024321
[ 0.000000] Kernel command line: BOOT_IMAGE=/vmlinuz root=/dev/sda2 rw quiet acpi_enforce_resources=lax video=efifb:off vga=0x318
[ 0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes)
[ 0.000000] Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes)
[ 0.000000] Inode-cache hash table entries: 524288 (order: 10, 4194304 bytes)
[ 0.000000] Checking aperture...
[ 0.000000] No AGP bridge found
[ 0.000000] Memory: 7768552k/9437184k available (7985k kernel code, 1211200k absent, 457432k reserved, 5076k data, 1120k init)
[ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[ 0.000000] Preemptible hierarchical RCU implementation.
[ 0.000000] RCU restricting CPUs from NR_CPUS=64 to nr_cpu_ids=4.
[ 0.000000] NR_IRQS:4352 nr_irqs:1024 16
[ 0.000000] Console: colour dummy device 80x25
[ 0.000000] console [tty0] enabled
[ 0.000000] allocated 33030144 bytes of page_cgroup
[ 0.000000] please try 'cgroup_disable=memory' option if you don't want memory cgroups
[ 0.000000] hpet clockevent registered
[ 0.000000] tsc: Fast TSC calibration using PIT
[ 0.001000] tsc: Detected 2000.082 MHz processor
[ 0.000004] Calibrating delay loop (skipped), value calculated using timer frequency.. 4000.16 BogoMIPS (lpj=2000082)
[ 0.000009] pid_max: default: 32768 minimum: 301
[ 0.000039] init_memory_mapping: [mem 0xb78e3000-0xb7b67fff]
[ 0.000043] [mem 0xb78e3000-0xb7b67fff] page 4k
[ 0.000065] init_memory_mapping: [mem 0xb7b68000-0xb7bb2fff]
[ 0.000068] [mem 0xb7b68000-0xb7bb2fff] page 4k
[ 0.000079] init_memory_mapping: [mem 0xb7bb4000-0xb7bf5fff]
[ 0.000082] [mem 0xb7bb4000-0xb7bf5fff] page 4k
[ 0.000092] init_memory_mapping: [mem 0xb7d65000-0xb7ff9fff]
[ 0.000095] [mem 0xb7d65000-0xb7ff9fff] page 4k
[ 0.001287] Security Framework initialized
[ 0.001360] Mount-cache hash table entries: 256
[ 0.001633] Initializing cgroup subsys debug
[ 0.001638] Initializing cgroup subsys memory
[ 0.001652] Initializing cgroup subsys devices
[ 0.001656] Initializing cgroup subsys freezer
[ 0.001660] Initializing cgroup subsys net_cls
[ 0.001663] Initializing cgroup subsys blkio
[ 0.001689] CPU: Physical Processor ID: 0
[ 0.001692] CPU: Processor Core ID: 0
[ 0.001697] ENERGY_PERF_BIAS: Set to 'normal', was 'performance'
[ 0.001697] ENERGY_PERF_BIAS: View and update with x86_energy_perf_policy(8)
[ 0.006509] mce: CPU supports 6 MCE banks
[ 0.006520] CPU0: Thermal monitoring enabled (TM1)
[ 0.006529] Last level iTLB entries: 4KB 0, 2MB 0, 4MB 0
[ 0.006529] Last level dTLB entries: 4KB 128, 2MB 0, 4MB 0
[ 0.006529] tlb_flushall_shift: 6
[ 0.006655] Freeing SMP alternatives: 32k freed
[ 0.006671] ACPI: Core revision 20130328
[ 0.018164] ACPI: All ACPI Tables successfully acquired
[ 0.032372] ftrace: allocating 29322 entries in 115 pages
[ 0.051108] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=0 pin2=0
[ 0.061117] smpboot: CPU0: Intel(R) Celeron(R) CPU J1900 @ 1.99GHz (fam: 06, model: 37, stepping: 03)
[ 0.061131] TSC deadline timer enabled
[ 0.061149] Performance Events: no PEBS fmt2+, generic architected perfmon, Intel PMU driver.
[ 0.061159] ... version: 3
[ 0.061162] ... bit width: 40
[ 0.061164] ... generic registers: 2
[ 0.061167] ... value mask: 000000ffffffffff
[ 0.061169] ... max period: 000000007fffffff
[ 0.061171] ... fixed-purpose events: 3
[ 0.061173] ... event mask: 0000000700000003
[ 0.068273] smpboot: Booting Node 0, Processors #1 #2 #3 OK
[ 0.126075] Brought up 4 CPUs
[ 0.126081] smpboot: Total of 4 processors activated (16000.65 BogoMIPS)
[ 0.126936] devtmpfs: initialized
[ 0.127354] PM: Registering ACPI NVS region [mem 0x0008f000-0x0008ffff] (4096 bytes)
[ 0.127359] PM: Registering ACPI NVS region [mem 0xb715c000-0xb78e2fff] (7892992 bytes)
[ 0.129228] xor: measuring software checksum speed
[ 0.139079] prefetch64-sse: 6648.000 MB/sec
[ 0.149100] generic_sse: 5960.000 MB/sec
[ 0.149103] xor: using function: prefetch64-sse (6648.000 MB/sec)
[ 0.149109] pinctrl core: initialized pinctrl subsystem
[ 0.149221] NET: Registered protocol family 16
[ 0.149490] ACPI FADT declares the system doesn't support PCIe ASPM, so disable it
[ 0.149495] ACPI: bus type PCI registered
[ 0.149579] PCI: Using configuration type 1 for base access
[ 0.152040] bio: create slab <bio-0> at 0
[ 0.169260] raid6: sse2x1 582 MB/s
[ 0.186240] raid6: sse2x2 660 MB/s
[ 0.203258] raid6: sse2x4 1136 MB/s
[ 0.203261] raid6: using algorithm sse2x4 (1136 MB/s)
[ 0.203264] raid6: using ssse3x2 recovery algorithm
[ 0.203362] ACPI: Added _OSI(Module Device)
[ 0.203367] ACPI: Added _OSI(Processor Device)
[ 0.203370] ACPI: Added _OSI(3.0 _SCP Extensions)
[ 0.203373] ACPI: Added _OSI(Processor Aggregator Device)
[ 0.206540] ACPI: EC: Look up EC in DSDT
[ 0.221204] ACPI: SSDT 00000000b7144c18 003BC (v01 PmRef Cpu0Ist 00003000 INTL 20061109)
[ 0.221995] ACPI: Dynamic OEM Table Load:
[ 0.222001] ACPI: SSDT (null) 003BC (v01 PmRef Cpu0Ist 00003000 INTL 20061109)
[ 0.222214] ACPI: SSDT 00000000b7143918 00433 (v01 PmRef Cpu0Cst 00003001 INTL 20061109)
[ 0.222989] ACPI: Dynamic OEM Table Load:
[ 0.222994] ACPI: SSDT (null) 00433 (v01 PmRef Cpu0Cst 00003001 INTL 20061109)
[ 0.228833] ACPI: SSDT 00000000b7145e18 0015F (v01 PmRef ApIst 00003000 INTL 20061109)
[ 0.229658] ACPI: Dynamic OEM Table Load:
[ 0.229663] ACPI: SSDT (null) 0015F (v01 PmRef ApIst 00003000 INTL 20061109)
[ 0.232507] ACPI: SSDT 00000000b7146f18 0008D (v01 PmRef ApCst 00003000 INTL 20061109)
[ 0.233282] ACPI: Dynamic OEM Table Load:
[ 0.233287] ACPI: SSDT (null) 0008D (v01 PmRef ApCst 00003000 INTL 20061109)
[ 0.236655] ACPI: Interpreter enabled
[ 0.236667] ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S1_] (20130328/hwxface-568)
[ 0.236677] ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S2_] (20130328/hwxface-568)
[ 0.236699] ACPI: (supports S0 S3 S5)
[ 0.236703] ACPI: Using IOAPIC for interrupt routing
[ 0.236762] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
[ 0.849396] ACPI: Power Resource [USBC] (on)
[ 0.849831] ACPI: Power Resource [FN00] (off)
[ 0.850958] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
[ 0.851863] PCI host bridge to bus 0000:00
[ 0.851870] pci_bus 0000:00: root bus resource [bus 00-ff]
[ 0.851875] pci_bus 0000:00: root bus resource [io 0x0000-0x006f]
[ 0.851879] pci_bus 0000:00: root bus resource [io 0x0078-0x0cf7]
[ 0.851883] pci_bus 0000:00: root bus resource [io 0x0d00-0xffff]
[ 0.851888] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff]
[ 0.851892] pci_bus 0000:00: root bus resource [mem 0x000c0000-0x000dffff]
[ 0.851896] pci_bus 0000:00: root bus resource [mem 0x000e0000-0x000fffff]
[ 0.851900] pci_bus 0000:00: root bus resource [mem 0xc0000000-0xd0816fff]
[ 0.851913] pci 0000:00:00.0: [8086:0f00] type 00 class 0x060000
[ 0.852106] pci 0000:00:02.0: [8086:0f31] type 00 class 0x030000
[ 0.852123] pci 0000:00:02.0: reg 10: [mem 0xd0000000-0xd03fffff]
[ 0.852137] pci 0000:00:02.0: reg 18: [mem 0xc0000000-0xcfffffff pref]
[ 0.852150] pci 0000:00:02.0: reg 20: [io 0xf080-0xf087]
[ 0.852361] pci 0000:00:13.0: [8086:0f23] type 00 class 0x010601
[ 0.852385] pci 0000:00:13.0: reg 10: [io 0xf070-0xf077]
[ 0.852396] pci 0000:00:13.0: reg 14: [io 0xf060-0xf063]
[ 0.852408] pci 0000:00:13.0: reg 18: [io 0xf050-0xf057]
[ 0.852419] pci 0000:00:13.0: reg 1c: [io 0xf040-0xf043]
[ 0.852430] pci 0000:00:13.0: reg 20: [io 0xf020-0xf03f]
[ 0.852442] pci 0000:00:13.0: reg 24: [mem 0xd0816000-0xd08167ff]
[ 0.852493] pci 0000:00:13.0: PME# supported from D3hot
[ 0.852676] pci 0000:00:14.0: [8086:0f35] type 00 class 0x0c0330
[ 0.852699] pci 0000:00:14.0: reg 10: [mem 0xd0800000-0xd080ffff 64bit]
[ 0.852763] pci 0000:00:14.0: PME# supported from D3hot D3cold
[ 0.852914] pci 0000:00:14.0: System wakeup disabled by ACPI
[ 0.852985] pci 0000:00:1a.0: [8086:0f18] type 00 class 0x108000
[ 0.853015] pci 0000:00:1a.0: reg 10: [mem 0xd0500000-0xd05fffff]
[ 0.853030] pci 0000:00:1a.0: reg 14: [mem 0xd0400000-0xd04fffff]
[ 0.853139] pci 0000:00:1a.0: PME# supported from D0 D3hot
[ 0.853315] pci 0000:00:1b.0: [8086:0f04] type 00 class 0x040300
[ 0.853342] pci 0000:00:1b.0: reg 10: [mem 0xd0810000-0xd0813fff 64bit]
[ 0.853418] pci 0000:00:1b.0: PME# supported from D0 D3hot D3cold
[ 0.853585] pci 0000:00:1c.0: [8086:0f48] type 01 class 0x060400
[ 0.853658] pci 0000:00:1c.0: PME# supported from D0 D3hot D3cold
[ 0.853827] pci 0000:00:1c.1: [8086:0f4a] type 01 class 0x060400
[ 0.853892] pci 0000:00:1c.1: PME# supported from D0 D3hot D3cold
[ 0.854059] pci 0000:00:1c.2: [8086:0f4c] type 01 class 0x060400
[ 0.854125] pci 0000:00:1c.2: PME# supported from D0 D3hot D3cold
[ 0.854292] pci 0000:00:1c.3: [8086:0f4e] type 01 class 0x060400
[ 0.854358] pci 0000:00:1c.3: PME# supported from D0 D3hot D3cold
[ 0.854535] pci 0000:00:1f.0: [8086:0f1c] type 00 class 0x060100
[ 0.854780] pci 0000:00:1f.3: [8086:0f12] type 00 class 0x0c0500
[ 0.854819] pci 0000:00:1f.3: reg 10: [mem 0xd0814000-0xd081401f]
[ 0.854893] pci 0000:00:1f.3: reg 20: [io 0xf000-0xf01f]
[ 0.855217] pci 0000:01:00.0: [10ec:8179] type 00 class 0x028000
[ 0.855238] pci 0000:01:00.0: reg 10: [io 0xe000-0xe0ff]
[ 0.855273] pci 0000:01:00.0: reg 18: [mem 0xd0700000-0xd0703fff 64bit]
[ 0.855373] pci 0000:01:00.0: supports D1 D2
[ 0.855377] pci 0000:01:00.0: PME# supported from D0 D1 D2 D3hot D3cold
[ 0.855423] pci 0000:01:00.0: System wakeup disabled by ACPI
[ 0.856629] pci 0000:00:1c.0: PCI bridge to [bus 01]
[ 0.856636] pci 0000:00:1c.0: bridge window [io 0xe000-0xefff]
[ 0.856642] pci 0000:00:1c.0: bridge window [mem 0xd0700000-0xd07fffff]
[ 0.856730] pci 0000:02:00.0: [10ec:5289] type 00 class 0xff0000
[ 0.856750] pci 0000:02:00.0: reg 10: [mem 0xd0600000-0xd060ffff]
[ 0.856878] pci 0000:02:00.0: supports D1 D2
[ 0.856882] pci 0000:02:00.0: PME# supported from D1 D2 D3hot D3cold
[ 0.856934] pci 0000:02:00.0: System wakeup disabled by ACPI
[ 0.857012] pci 0000:02:00.2: [10ec:8168] type 00 class 0x020000
[ 0.857032] pci 0000:02:00.2: reg 10: [io 0xd000-0xd0ff]
[ 0.857063] pci 0000:02:00.2: reg 18: [mem 0xd0614000-0xd0614fff 64bit pref]
[ 0.857083] pci 0000:02:00.2: reg 20: [mem 0xd0610000-0xd0613fff 64bit pref]
[ 0.857161] pci 0000:02:00.2: supports D1 D2
[ 0.857166] pci 0000:02:00.2: PME# supported from D0 D1 D2 D3hot D3cold
[ 0.857221] pci 0000:02:00.2: System wakeup disabled by ACPI
[ 0.858636] pci 0000:00:1c.1: PCI bridge to [bus 02]
[ 0.858643] pci 0000:00:1c.1: bridge window [io 0xd000-0xdfff]
[ 0.858649] pci 0000:00:1c.1: bridge window [mem 0xd0600000-0xd06fffff]
[ 0.858717] pci 0000:00:1c.2: PCI bridge to [bus 03]
[ 0.858786] pci 0000:00:1c.3: PCI bridge to [bus 04]
[ 0.858811] pci_bus 0000:00: on NUMA node 0
[ 0.859024] acpi PNP0A08:00: Unable to request _OSC control (_OSC support mask: 0x1e)
[ 1.060595] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 10 *11 12 14 15)
[ 1.060738] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 *10 11 12 14 15)
[ 1.060882] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 *5 6 10 11 12 14 15)
[ 1.061033] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 *10 11 12 14 15)
[ 1.061174] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 *5 6 10 11 12 14 15)
[ 1.061314] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 10 11 12 14 15) *0, disabled.
[ 1.061456] ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 10 *11 12 14 15)
[ 1.061597] ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 10 *11 12 14 15)
[ 1.062268] ACPI: Enabled 6 GPEs in block 00 to 3F
[ 1.062284] acpi root: \_SB_.PCI0 notify handler is installed
[ 1.062391] Found 1 acpi root devices
[ 1.062575] vgaarb: device added: PCI:0000:00:02.0,decodes=io+mem,owns=io+mem,locks=none
[ 1.062582] vgaarb: loaded
[ 1.062584] vgaarb: bridge control possible 0000:00:02.0
[ 1.062688] SCSI subsystem initialized
[ 1.062693] ACPI: bus type ATA registered
[ 1.062786] libata version 3.00 loaded.
[ 1.062827] ACPI: bus type USB registered
[ 1.062863] usbcore: registered new interface driver usbfs
[ 1.062880] usbcore: registered new interface driver hub
[ 1.062925] usbcore: registered new device driver usb
[ 1.062977] pps_core: LinuxPPS API ver. 1 registered
[ 1.062980] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[ 1.062988] PTP clock support registered
[ 1.063147] Advanced Linux Sound Architecture Driver Initialized.
[ 1.063151] PCI: Using ACPI for IRQ routing
[ 1.063156] PCI: pci_cache_line_size set to 64 bytes
[ 1.063208] e820: reserve RAM buffer [mem 0x0008f000-0x0008ffff]
[ 1.063212] e820: reserve RAM buffer [mem 0x1f000000-0x1fffffff]
[ 1.063215] e820: reserve RAM buffer [mem 0xb711c000-0xb7ffffff]
[ 1.063219] e820: reserve RAM buffer [mem 0xb7bb4000-0xb7ffffff]
[ 1.063222] e820: reserve RAM buffer [mem 0xb7d65000-0xb7ffffff]
[ 1.063504] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0
[ 1.063513] hpet0: 3 comparators, 64-bit 14.318180 MHz counter
[ 1.065540] Switching to clocksource hpet
[ 1.075332] pnp: PnP ACPI init
[ 1.075358] ACPI: bus type PNP registered
[ 1.075439] pnp 00:00: Plug and Play ACPI device, IDs PNP0b00 (active)
[ 1.075554] pnp 00:01: Plug and Play ACPI device, IDs PNP0103 (active)
[ 1.075740] pnp 00:02: Plug and Play ACPI device, IDs INT0800 (active)
[ 1.075827] system 00:03: [io 0x0680-0x069f] has been reserved
[ 1.075833] system 00:03: [io 0x0400-0x047f] has been reserved
[ 1.075838] system 00:03: [io 0x0500-0x05fe] has been reserved
[ 1.075843] system 00:03: [io 0x0600-0x061f] has been reserved
[ 1.075849] system 00:03: Plug and Play ACPI device, IDs PNP0c02 (active)
[ 1.076171] system 00:04: [io 0x0a00-0x0a2f] has been reserved
[ 1.076177] system 00:04: [io 0x0a30-0x0a3f] has been reserved
[ 1.076181] system 00:04: [io 0x0a40-0x0a4f] has been reserved
[ 1.076187] system 00:04: Plug and Play ACPI device, IDs PNP0c02 (active)
[ 1.076725] pnp 00:05: [dma 0 disabled]
[ 1.076821] pnp 00:05: Plug and Play ACPI device, IDs PNP0501 (active)
[ 1.077330] pnp 00:06: [dma 0 disabled]
[ 1.077423] pnp 00:06: Plug and Play ACPI device, IDs PNP0501 (active)
[ 1.277023] system 00:07: [mem 0xe0000000-0xefffffff] could not be reserved
[ 1.277029] system 00:07: [mem 0xfed01000-0xfed01fff] has been reserved
[ 1.277034] system 00:07: [mem 0xfed03000-0xfed03fff] has been reserved
[ 1.277038] system 00:07: [mem 0xfed04000-0xfed04fff] has been reserved
[ 1.277043] system 00:07: [mem 0xfed0c000-0xfed0ffff] has been reserved
[ 1.277048] system 00:07: [mem 0xfed08000-0xfed08fff] has been reserved
[ 1.277052] system 00:07: [mem 0xfed1c000-0xfed1cfff] has been reserved
[ 1.277057] system 00:07: [mem 0xfee00000-0xfeefffff] has been reserved
[ 1.277061] system 00:07: [mem 0xfef00000-0xfeffffff] has been reserved
[ 1.277068] system 00:07: Plug and Play ACPI device, IDs PNP0c02 (active)
[ 1.277450] pnp: PnP ACPI: found 8 devices
[ 1.277454] ACPI: bus type PNP unregistered
[ 1.286344] pci 0000:00:1c.0: bridge window [mem 0x00100000-0x000fffff 64bit pref] to [bus 01] add_size 200000
[ 1.286357] pci 0000:00:1c.1: bridge window [mem 0x00100000-0x000fffff 64bit pref] to [bus 02] add_size 200000
[ 1.286368] pci 0000:00:1c.2: bridge window [io 0x1000-0x0fff] to [bus 03] add_size 1000
[ 1.286373] pci 0000:00:1c.2: bridge window [mem 0x00100000-0x000fffff 64bit pref] to [bus 03] add_size 200000
[ 1.286378] pci 0000:00:1c.2: bridge window [mem 0x00100000-0x000fffff] to [bus 03] add_size 200000
[ 1.286388] pci 0000:00:1c.3: bridge window [io 0x1000-0x0fff] to [bus 04] add_size 1000
[ 1.286393] pci 0000:00:1c.3: bridge window [mem 0x00100000-0x000fffff 64bit pref] to [bus 04] add_size 200000
[ 1.286398] pci 0000:00:1c.3: bridge window [mem 0x00100000-0x000fffff] to [bus 04] add_size 200000
[ 1.286409] pci 0000:00:1c.0: res[9]=[mem 0x00100000-0x000fffff 64bit pref] get_res_add_size add_size 200000
[ 1.286414] pci 0000:00:1c.1: res[9]=[mem 0x00100000-0x000fffff 64bit pref] get_res_add_size add_size 200000
[ 1.286418] pci 0000:00:1c.2: res[8]=[mem 0x00100000-0x000fffff] get_res_add_size add_size 200000
[ 1.286423] pci 0000:00:1c.2: res[9]=[mem 0x00100000-0x000fffff 64bit pref] get_res_add_size add_size 200000
[ 1.286427] pci 0000:00:1c.3: res[8]=[mem 0x00100000-0x000fffff] get_res_add_size add_size 200000
[ 1.286432] pci 0000:00:1c.3: res[9]=[mem 0x00100000-0x000fffff 64bit pref] get_res_add_size add_size 200000
[ 1.286436] pci 0000:00:1c.2: res[7]=[io 0x1000-0x0fff] get_res_add_size add_size 1000
[ 1.286441] pci 0000:00:1c.3: res[7]=[io 0x1000-0x0fff] get_res_add_size add_size 1000
[ 1.286450] pci 0000:00:1c.0: BAR 9: can't assign mem pref (size 0x200000)
[ 1.286457] pci 0000:00:1c.1: BAR 9: can't assign mem pref (size 0x200000)
[ 1.286463] pci 0000:00:1c.2: BAR 8: can't assign mem (size 0x200000)
[ 1.286469] pci 0000:00:1c.2: BAR 9: can't assign mem pref (size 0x200000)
[ 1.286474] pci 0000:00:1c.3: BAR 8: can't assign mem (size 0x200000)
[ 1.286480] pci 0000:00:1c.3: BAR 9: can't assign mem pref (size 0x200000)
[ 1.286487] pci 0000:00:1c.2: BAR 7: assigned [io 0x1000-0x1fff]
[ 1.286492] pci 0000:00:1c.3: BAR 7: assigned [io 0x2000-0x2fff]
[ 1.286500] pci 0000:00:1c.3: BAR 8: can't assign mem (size 0x200000)
[ 1.286506] pci 0000:00:1c.3: BAR 9: can't assign mem pref (size 0x200000)
[ 1.286512] pci 0000:00:1c.2: BAR 8: can't assign mem (size 0x200000)
[ 1.286518] pci 0000:00:1c.2: BAR 9: can't assign mem pref (size 0x200000)
[ 1.286524] pci 0000:00:1c.1: BAR 9: can't assign mem pref (size 0x200000)
[ 1.286530] pci 0000:00:1c.0: BAR 9: can't assign mem pref (size 0x200000)
[ 1.286535] pci 0000:00:1c.0: PCI bridge to [bus 01]
[ 1.286540] pci 0000:00:1c.0: bridge window [io 0xe000-0xefff]
[ 1.286547] pci 0000:00:1c.0: bridge window [mem 0xd0700000-0xd07fffff]
[ 1.286557] pci 0000:00:1c.1: PCI bridge to [bus 02]
[ 1.286573] pci 0000:00:1c.1: bridge window [io 0xd000-0xdfff]
[ 1.286580] pci 0000:00:1c.1: bridge window [mem 0xd0600000-0xd06fffff]
[ 1.286589] pci 0000:00:1c.2: PCI bridge to [bus 03]
[ 1.286593] pci 0000:00:1c.2: bridge window [io 0x1000-0x1fff]
[ 1.286605] pci 0000:00:1c.3: PCI bridge to [bus 04]
[ 1.286609] pci 0000:00:1c.3: bridge window [io 0x2000-0x2fff]
[ 1.287114] pci_bus 0000:00: resource 4 [io 0x0000-0x006f]
[ 1.287120] pci_bus 0000:00: resource 5 [io 0x0078-0x0cf7]
[ 1.287124] pci_bus 0000:00: resource 6 [io 0x0d00-0xffff]
[ 1.287128] pci_bus 0000:00: resource 7 [mem 0x000a0000-0x000bffff]
[ 1.287132] pci_bus 0000:00: resource 8 [mem 0x000c0000-0x000dffff]
[ 1.287136] pci_bus 0000:00: resource 9 [mem 0x000e0000-0x000fffff]
[ 1.287140] pci_bus 0000:00: resource 10 [mem 0xc0000000-0xd0816fff]
[ 1.287145] pci_bus 0000:01: resource 0 [io 0xe000-0xefff]
[ 1.287149] pci_bus 0000:01: resource 1 [mem 0xd0700000-0xd07fffff]
[ 1.287153] pci_bus 0000:02: resource 0 [io 0xd000-0xdfff]
[ 1.287157] pci_bus 0000:02: resource 1 [mem 0xd0600000-0xd06fffff]
[ 1.287161] pci_bus 0000:03: resource 0 [io 0x1000-0x1fff]
[ 1.287165] pci_bus 0000:04: resource 0 [io 0x2000-0x2fff]
[ 1.287217] NET: Registered protocol family 2
[ 1.287555] TCP established hash table entries: 65536 (order: 8, 1048576 bytes)
[ 1.287898] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
[ 1.288231] TCP: Hash tables configured (established 65536 bind 65536)
[ 1.288295] TCP: reno registered
[ 1.288306] UDP hash table entries: 4096 (order: 5, 131072 bytes)
[ 1.288368] UDP-Lite hash table entries: 4096 (order: 5, 131072 bytes)
[ 1.288545] NET: Registered protocol family 1
[ 1.288740] RPC: Registered named UNIX socket transport module.
[ 1.288744] RPC: Registered udp transport module.
[ 1.288746] RPC: Registered tcp transport module.
[ 1.288749] RPC: Registered tcp NFSv4.1 backchannel transport module.
[ 1.288765] pci 0000:00:02.0: Boot video device
[ 1.289102] PCI: CLS 64 bytes, default 64
[ 1.289182] PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
[ 1.289188] software IO TLB [mem 0xa4ae6000-0xa8ae6000] (64MB) mapped at [ffff8800a4ae6000-ffff8800a8ae5fff]
[ 1.289471] Scanning for low memory corruption every 60 seconds
[ 1.289627] Uptime: system uptime restrictions enabled
[ 1.337796] NFS: Registering the id_resolver key type
[ 1.337824] Key type id_resolver registered
[ 1.337827] Key type id_legacy registered
[ 1.338135] bio: create slab <bio-1> at 1
[ 1.338342] Btrfs loaded
[ 1.338486] aufs 3.10-20130819
[ 1.338495] msgmni has been set to 15629
[ 1.339059] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 251)
[ 1.339064] io scheduler noop registered
[ 1.339067] io scheduler deadline registered
[ 1.339077] io scheduler cfq registered (default)
[ 1.339347] byt_gpio byt_gpio.2: GPIO interrupt error, pins misconfigured
[ 1.339507] byt_gpio byt_gpio.2: Gpio 1 interrupt flood, disabling
[ 1.339668] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
[ 1.339719] intel_idle: does not run on family 6 model 55
[ 1.339838] input: Power Button as /devices/LNXSYSTM:00/device:00/PNP0C0C:00/input/input0
[ 1.339847] ACPI: Power Button [PWRB]
[ 1.339915] input: Sleep Button as /devices/LNXSYSTM:00/device:00/PNP0C0E:00/input/input1
[ 1.339921] ACPI: Sleep Button [SLPB]
[ 1.339984] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input2
[ 1.339989] ACPI: Power Button [PWRF]
[ 1.340115] ACPI: Fan [FAN0] (off)
[ 1.340227] ACPI: Requesting acpi_cpufreq
[ 1.343233] Monitor-Mwait will be used to enter C-1 state
[ 1.343262] Monitor-Mwait will be used to enter C-2 state
[ 1.343317] ACPI: acpi_idle registered with cpuidle
[ 1.550964] thermal LNXTHERM:00: registered as thermal_zone0
[ 1.550970] ACPI: Thermal Zone [TZ01] (27 C)
[ 1.575624] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
[ 1.596370] 00:05: ttyS0 at I/O 0x3f8 (irq = 3) is a 16550A
[ 1.617140] 00:06: ttyS1 at I/O 0x2f8 (irq = 4) is a 16550A
[ 1.617787] Linux agpgart interface v0.103
[ 1.617834] [drm] Initialized drm 1.1.0 20060810
[ 1.618422] [drm] Memory usable by graphics device = 2048M
[ 1.618433] i915 0000:00:02.0: setting latency timer to 64
[ 1.623040] i915 0000:00:02.0: irq 103 for MSI/MSI-X
[ 1.623058] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[ 1.623061] [drm] Driver supports precise vblank timestamp query.
[ 1.623156] vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
[ 1.641576] [drm] failed to retrieve link info, disabling eDP
[ 1.738888] fbcon: inteldrmfb (fb0) is primary device
[ 1.985947] Console: switching to colour frame buffer device 170x48
[ 1.993260] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device
[ 1.993264] i915 0000:00:02.0: registered panic notifier
[ 2.000617] acpi device:0a: registered as cooling_device5
[ 2.000659] ACPI: Video Device [GFX0] (multi-head: yes rom: no post: no)
[ 2.000723] input: Video Bus as /devices/LNXSYSTM:00/device:00/PNP0A08:00/LNXVIDEO:00/input/input3
[ 2.000754] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0
[ 2.003145] brd: module loaded
[ 2.004417] loop: module loaded
[ 2.004510] ahci 0000:00:13.0: version 3.0
[ 2.004720] ahci 0000:00:13.0: irq 104 for MSI/MSI-X
[ 2.015593] ahci 0000:00:13.0: AHCI 0001.0300 32 slots 2 ports 3 Gbps 0x1 impl SATA mode
[ 2.015600] ahci 0000:00:13.0: flags: 64bit ncq pm led clo pio slum part deso sadm apst
[ 2.015607] ahci 0000:00:13.0: setting latency timer to 64
[ 2.015994] scsi0 : ahci
[ 2.016126] scsi1 : ahci
[ 2.016195] ata1: SATA max UDMA/133 abar m2048@0xd0816000 port 0xd0816100 irq 104
[ 2.016199] ata2: DUMMY
[ 2.016306] pcnet32: pcnet32.c:v1.35 21.Apr.2008 tsbogend@alpha.franken.de
[ 2.016344] e100: Intel(R) PRO/100 Network Driver, 3.5.24-k2-NAPI
[ 2.016347] e100: Copyright(c) 1999-2006 Intel Corporation
[ 2.016369] e1000: Intel(R) PRO/1000 Network Driver - version 7.3.21-k8-NAPI
[ 2.016371] e1000: Copyright (c) 1999-2006 Intel Corporation.
[ 2.016392] e1000e: Intel(R) PRO/1000 Network Driver - 2.3.2-k
[ 2.016394] e1000e: Copyright(c) 1999 - 2013 Intel Corporation.
[ 2.016467] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[ 2.016470] ehci-pci: EHCI PCI platform driver
[ 2.016660] xhci_hcd 0000:00:14.0: setting latency timer to 64
[ 2.016666] xhci_hcd 0000:00:14.0: xHCI Host Controller
[ 2.016676] xhci_hcd 0000:00:14.0: new USB bus registered, assigned bus number 1
[ 2.017076] xhci_hcd 0000:00:14.0: cache line size of 64 is not supported
[ 2.017106] xhci_hcd 0000:00:14.0: irq 105 for MSI/MSI-X
[ 2.017328] xHCI xhci_add_endpoint called for root hub
[ 2.017332] xHCI xhci_check_bandwidth called for root hub
[ 2.017380] hub 1-0:1.0: USB hub found
[ 2.017394] hub 1-0:1.0: 6 ports detected
[ 2.018178] xhci_hcd 0000:00:14.0: xHCI Host Controller
[ 2.018186] xhci_hcd 0000:00:14.0: new USB bus registered, assigned bus number 2
[ 2.018343] xHCI xhci_add_endpoint called for root hub
[ 2.018346] xHCI xhci_check_bandwidth called for root hub
[ 2.018392] hub 2-0:1.0: USB hub found
[ 2.018401] hub 2-0:1.0: 1 port detected
[ 2.025634] usbcore: registered new interface driver usb-storage
[ 2.025685] i8042: PNP: No PS/2 controller found. Probing ports directly.
[ 2.291593] tsc: Refined TSC clocksource calibration: 1999.999 MHz
[ 2.291600] Switching to clocksource tsc
[ 2.546595] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 2.546899] ata1.00: ATA-8: INTEL SSDSA2CW120G3, 4PC10362, max UDMA/133
[ 2.546905] ata1.00: 234441648 sectors, multi 16: LBA48 NCQ (depth 31/32)
[ 2.547226] ata1.00: configured for UDMA/133
[ 2.547383] scsi 0:0:0:0: Direct-Access ATA INTEL SSDSA2CW12 4PC1 PQ: 0 ANSI: 5
[ 2.547619] sd 0:0:0:0: Attached scsi generic sg0 type 0
[ 2.547745] sd 0:0:0:0: [sda] 234441648 512-byte logical blocks: (120 GB/111 GiB)
[ 2.547899] sd 0:0:0:0: [sda] Write Protect is off
[ 2.547905] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 2.547955] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 2.550750] sda: sda1 sda2 sda3
[ 2.551305] sd 0:0:0:0: [sda] Attached SCSI disk
[ 2.799581] usb 1-3: new full-speed USB device number 2 using xhci_hcd
[ 2.811010] usb 1-3: ep 0x81 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[ 2.811237] hub 1-3:1.0: USB hub found
[ 2.811337] hub 1-3:1.0: 4 ports detected
[ 2.964581] usb 1-4: new high-speed USB device number 3 using xhci_hcd
[ 2.977246] hub 1-4:1.0: USB hub found
[ 2.977486] hub 1-4:1.0: 4 ports detected
[ 3.068301] i8042: No controller found
[ 3.068488] mousedev: PS/2 mouse device common for all mice
[ 3.069013] ACPI Warning: 0x000000000000f000-0x000000000000f01f SystemIO conflicts with Region \_SB_.PCI0.SBUS.SMBI 1 (20130328/utaddress-251)
[ 3.069023] ACPI: This conflict may cause random problems and system instability
[ 3.069026] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
[ 3.069078] i801_smbus 0000:00:1f.3: SMBus using PCI Interrupt
[ 3.069149] md: linear personality registered for level -1
[ 3.069153] md: raid0 personality registered for level 0
[ 3.069156] md: raid1 personality registered for level 1
[ 3.069158] md: raid10 personality registered for level 10
[ 3.069161] md: multipath personality registered for level -4
[ 3.069164] md: faulty personality registered for level -5
[ 3.069333] device-mapper: ioctl: 4.24.0-ioctl (2013-01-15) initialised: dm-devel@redhat.com
[ 3.069468] cpuidle: using governor ladder
[ 3.069622] cpuidle: using governor menu
[ 3.069639] sdhci: Secure Digital Host Controller Interface driver
[ 3.069642] sdhci: Copyright(c) Pierre Ossman
[ 3.069729] usbcore: registered new interface driver usbhid
[ 3.069732] usbhid: USB HID core driver
[ 3.070009] snd_hda_intel 0000:00:1b.0: irq 106 for MSI/MSI-X
[ 3.070052] snd_hda_intel 0000:00:1b.0: setting latency timer to 64
[ 3.073621] usb 1-3.1: new full-speed USB device number 4 using xhci_hcd
[ 3.116694] usb 1-3.1: ep 0x81 - rounding interval to 64 microframes, ep desc says 80 microframes
[ 3.116703] usb 1-3.1: ep 0x82 - rounding interval to 64 microframes, ep desc says 80 microframes
[ 3.116709] usb 1-3.1: ep 0x83 - rounding interval to 32 microframes, ep desc says 40 microframes
[ 3.125105] oprofile: using NMI interrupt.
[ 3.125210] u32 classifier
[ 3.125214] Actions configured
[ 3.125320] TCP: cubic registered
[ 3.125511] NET: Registered protocol family 10
[ 3.125776] sit: IPv6 over IPv4 tunneling driver
[ 3.125954] NET: Registered protocol family 17
[ 3.125993] Key type dns_resolver registered
[ 3.127092] input: Chicony USB Keyboard as /devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3.1/1-3.1:1.0/input/input4
[ 3.127179] hid-generic 0003:04F2:0402.0001: input: USB HID v1.11 Keyboard [Chicony USB Keyboard] on usb-0000:00:14.0-3.1/input0
[ 3.127234] console [netcon0] enabled
[ 3.127238] netconsole: network logging started
[ 3.128375] ALSA device list:
[ 3.128379] #0: HDA Intel PCH at 0xd0810000 irq 106
[ 3.168416] input: Chicony USB Keyboard as /devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3.1/1-3.1:1.1/input/input5
[ 3.168617] hid-generic 0003:04F2:0402.0002: input: USB HID v1.11 Device [Chicony USB Keyboard] on usb-0000:00:14.0-3.1/input1
[ 3.176644] input: Chicony USB Keyboard as /devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3.1/1-3.1:1.2/input/input6
[ 3.177442] hid-generic 0003:04F2:0402.0003: input: USB HID v1.10 Mouse [Chicony USB Keyboard] on usb-0000:00:14.0-3.1/input2
[ 3.177646] md: Waiting for all devices to be available before autodetect
[ 3.177655] md: If you don't use raid, use raid=noautodetect
[ 3.178069] md: Autodetecting RAID arrays.
[ 3.178075] md: Scanned 0 and added 0 devices.
[ 3.178078] md: autorun ...
[ 3.178081] md: ... autorun DONE.
[ 3.181129] kjournald starting. Commit interval 5 seconds
[ 3.181349] EXT3-fs (sda2): using internal journal
[ 3.181356] EXT3-fs (sda2): mounted filesystem with ordered data mode
[ 3.181377] VFS: Mounted root (ext3 filesystem) on device 8:2.
[ 3.181884] devtmpfs: mounted
[ 3.184335] Freeing unused kernel memory: 1120k freed
[ 3.184748] Write protecting the kernel read-only data: 12288k
[ 3.186869] Freeing unused kernel memory: 200k freed
[ 3.190950] Freeing unused kernel memory: 744k freed
[ 3.262544] Adding 5860348k swap on /dev/sda3. Priority:-1 extents:1 across:5860348k SS
[ 3.298956] udevd[96]: starting version 182
[ 3.411175] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
[ 3.411492] r8169 0000:02:00.2: irq 107 for MSI/MSI-X
[ 3.411794] r8169 0000:02:00.2 eth0: RTL8411 at 0xffffc90000022000, xx:xx:xx:xx:xx:xx, XID 08800800 IRQ 107
[ 3.411799] r8169 0000:02:00.2 eth0: jumbo features [frames: 9200 bytes, tx checksumming: ko]
[ 3.629823] i2c /dev entries driver
[ 3.647364] cfg80211: Calling CRDA to update world regulatory domain
[ 3.650624] Intel(R) Wireless WiFi driver for Linux, in-tree:
[ 3.650630] Copyright(c) 2003-2013 Intel Corporation
[ 6.547853] r8169 0000:02:00.2 eth0: link down
[ 6.547865] r8169 0000:02:00.2 eth0: link down
[ 6.547912] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 8.180496] r8169 0000:02:00.2 eth0: link up
[ 8.180514] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 10.283515] r8169 0000:02:00.2 eth0: link down
[ 10.283525] r8169 0000:02:00.2 eth0: link down
[ 10.283573] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 11.906696] r8169 0000:02:00.2 eth0: link up
[ 11.906725] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

上のカーネル・ログには、DE3815TYKHEと比較していくつか気になる点も存在するのですが、カーネルの動作に影響を及ぼすようなエラーはないようです。

ちなみに、EthernetデバイスはRTL8411という型番のようですね。Realtekのサイトで確認すると、このデバイスはEthernet ControllerとCard Reader Controllerの統合チップのようです。上のdmesgコマンドの出力情報によると、r8169ドライバのロードと初期化処理が実行されていることが判ります。ifconfigコマンドで確認すると、やはりeth0インターフェースが生成されていました。Valley Island BSP Dasiy 1.6.2にはRTL8168/8169/8111ドライバが組み込まれていますが、このドライバはRTL8411にも対応しているのでしょう。

じつは、上記の各コマンドはシリアル端末からYocto Linuxへログインした状態で実行しました。Valley Island BSPからビルドしたイメージの/etc/inittab内には、シリアル・デバイス/dev/ttyS0(COM1に相当)に対するgetty起動設定が存在しています。そのため、シリアル経由で接続したPC側で端末ソフトを起動していれば、カーネルのブート後にログイン・プロンプトが表示されます。こういう環境を欲しかったことがXS36V4を入手した最大の目的でした。どうしてもネットワークが使えない現場が稀に存在しますが、こういう現場でも、XS36V4ならシリアル経由でコントロールすることができます。

少しはトラブルに遭遇るんじゃないかと想像していたのですが、XS36V4でYocto Linuxを動かすというゴールにすんなりと到達してしまいました。じつは、今回XS36V4を入手した目的はもう一つあります。それは、この機種でTizenを動かしてみることです。Yocto Linuxの魅力にハマってからですが、私はTizenにも注目するようになりました。その理由は、Tizenプロジェクトを主導しているのがIntelだからです。Intelが主導しているプロジェクトなら技術的に得られるものが大きいので、研究テーマとして本格的に取り組む価値が十分にあると考えています。Tizenのターゲットには、Intel E38xxを搭載した産業用PCがいくつか含まれています。Yocto Linuxと同じように、E38xxで動くならJ1800/1900でもきっとTizenが動くはずです。近いうちに、XS36V4でTizenを動かすことに挑戦するつもりです。乞うご期待ください。






posted by とみやん at 08:11| Comment(0) | TrackBack(0) | Embedded Linux > Yocto Project

2015年01月05日

[Yocto] cryptsetup AES-NI対応機能の有効化

01/02の記事で、Linux用の暗号化ファイルシステムLUKSというものを紹介しました。この記事の中で、LUKSファイルシステムの読み書き速度の性能評価をやりましたが、その計測値が期待していたよりかなり低かったことから、cryptsetupの暗号処理でAES-NIが使われていないのではないかという疑惑が生まれました。

Yocto LinuxのcryptsetupのレシピやValley Island BSPのカーネル・コンフィグレーション設定などを調べていくうちに、やはりこの疑惑が正しいことが判りました。そして、cryptsetupのAES-NI対応機能を有効する方法も見つけました。

結論を先に書くと、DE3815TYKHE BSPのカーネルレシピを以下のように変更すると、cryptsetupのAES-NI対応機能が有効になります(Valley Island BSPも同様)。
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"

#############################
# MACHINE = de3815tybe-32 #
#############################
COMPATIBLE_MACHINE_de3815tybe-32 = "de3815tybe-32"
KMACHINE_de3815tybe-32 = "valleyisland-32"
KBRANCH_de3815tybe-32 = "standard/base"
KERNEL_FEATURES_de3815tybe-32 = " features/valleyisland-io/valleyisland-io.scc \
features/valleyisland-io/valleyisland-io-pci.scc \
features/ciphers/ciphers.scc \
features/wifi/wifi-all.scc"

LINUX_VERSION_de3815tybe-32 = "3.10.59"
SRCREV_machine_de3815tybe-32 = "747e1cbd12b15db8bc2ae86e2359c1b113f120d6"
SRCREV_meta_de3815tybe-32 = "8f05306a8e6f5ee422d50c3317acce0cf9e6aada"
SRCREV_valleyisland-io_de3815tybe-32 = "0992d01f5f382f6da60004ef87f67ebd3ca13732"

SRC_URI_de3815tybe-32 = "git://git.yoctoproject.org/linux-yocto-3.10.git;protocol=git;nocheckout=1;branch=${KBRANCH},${KMETA},valleyisland-io-3.0;name=machine,meta,valleyisland-io"

#############################
# MACHINE = de3815tybe-64 #
#############################
COMPATIBLE_MACHINE_de3815tybe-64 = "de3815tybe-64"
KMACHINE_de3815tybe-64 = "valleyisland"
KBRANCH_de3815tybe-64 = "standard/base"
KERNEL_FEATURES_de3815tybe-64 = " features/valleyisland-io/valleyisland-io.scc \
features/valleyisland-io/valleyisland-io-pci.scc \
features/ciphers/ciphers.scc \
features/wifi/wifi-all.scc"

LINUX_VERSION_de3815tybe-64 = "3.10.59"
SRCREV_machine_de3815tybe-64 = "747e1cbd12b15db8bc2ae86e2359c1b113f120d6"
SRCREV_meta_de3815tybe-64 = "8f05306a8e6f5ee422d50c3317acce0cf9e6aada"
SRCREV_valleyisland-io_de3815tybe-64 = "0992d01f5f382f6da60004ef87f67ebd3ca13732"

SRC_URI_de3815tybe-64 = "git://git.yoctoproject.org/linux-yocto-3.10.git;protocol=git;nocheckout=1;branch=${KBRANCH},${KMETA},valleyisland-io-3.0;name=machine,meta,valleyisland-io"

module_autoload_i2c-dev = "i2c-dev"

linux-yocto_3.10.bbappendに上記のような変更を加えると、カーネルの以下のコンフィグレーション設定項目が有効になります。
CONFIG_CRYPTO_AES_NI_INTEL

-*- Cryptographic API --->
*** Ciphers ***
<*> AES cipher algorithms (AES-NI)


■ LUKSファイルシステムAES-NI対応機能の性能評価


cryptsetupには暗号処理のベンチマーク機能が搭載されています。「cryptsetup benchmark」というコマンドによって、その機能を動かすことができます。

01/02の記事の追記にすでに掲載済みですが、AES-NIが無効な場合のcryptsetup自身による暗号処理のベンチマーク計測値を改めて示します。
# cryptsetup benchmark
# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1 377729 iterations per second
PBKDF2-sha256 236165 iterations per second
PBKDF2-sha512 186712 iterations per second
PBKDF2-ripemd160 298229 iterations per second
PBKDF2-whirlpool 109044 iterations per second
# Algorithm | Key | Encryption | Decryption
aes-cbc 128b 48.0 MiB/s 57.4 MiB/s
serpent-cbc 128b 23.3 MiB/s 24.7 MiB/s
twofish-cbc 128b 45.1 MiB/s 53.9 MiB/s
aes-cbc 256b 38.6 MiB/s 43.8 MiB/s
serpent-cbc 256b 23.3 MiB/s 24.8 MiB/s
twofish-cbc 256b 45.1 MiB/s 53.9 MiB/s
aes-xts 256b 57.6 MiB/s 58.5 MiB/s
serpent-xts 256b 25.3 MiB/s 25.0 MiB/s
twofish-xts 256b 53.4 MiB/s 54.8 MiB/s
aes-xts 512b 44.4 MiB/s 44.4 MiB/s
serpent-xts 512b 25.3 MiB/s 25.0 MiB/s
twofish-xts 512b 53.4 MiB/s 54.8 MiB/s

比較のために、AES-NIが有効な場合の同コマンドの実行結果を以下に示します。
# cryptsetup benchmark
# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1 379369 iterations per second
PBKDF2-sha256 236592 iterations per second
PBKDF2-sha512 186712 iterations per second
PBKDF2-ripemd160 298569 iterations per second
PBKDF2-whirlpool 109409 iterations per second
# Algorithm | Key | Encryption | Decryption
aes-cbc 128b 203.3 MiB/s 284.3 MiB/s
serpent-cbc 128b 23.4 MiB/s 24.9 MiB/s
twofish-cbc 128b 45.2 MiB/s 54.2 MiB/s
aes-cbc 256b 159.4 MiB/s 226.1 MiB/s
serpent-cbc 256b 23.4 MiB/s 25.0 MiB/s
twofish-cbc 256b 45.3 MiB/s 54.1 MiB/s
aes-xts 256b 256.0 MiB/s 257.1 MiB/s
serpent-xts 256b 25.3 MiB/s 25.0 MiB/s
twofish-xts 256b 53.8 MiB/s 55.0 MiB/s
aes-xts 512b 204.3 MiB/s 205.7 MiB/s
serpent-xts 512b 25.4 MiB/s 25.0 MiB/s
twofish-xts 512b 53.7 MiB/s 54.9 MiB/s

上の2つのケースの計測値を比較すると、aes-cbcとaes-xtsの性能に4〜5倍の差が出ています。OpenSSLによる性能差より少し低いですが、暗号処理エンジンとしてのAES-NIの性能は相当優秀であることがこの結果から判ります。

cryptsetupのAES-NI対応機能を有効した状態で、LUKSファイルシステムの読み書き速度の性能評価を改めてやってみました。01/02の記事と同じ方法を使って計測を行いました。以下に、LUKSファイルシステムの読み書き速度の計測結果を示します。

ファイルシステム読み込み速度(MB/sec)比率書き込み速度(MB/sec)比率
素のext3263.3694.96
LUKS ext3 AES-NI無効41.120.1542.400.44
LUKS ext3 AES-NI有効95.490.3690.720.95

AES-NIが有効な場合の計測値は期待していたほど向上していませんでした。もしかすると読み込み速度は200MB/sec位いくんじゃないかと予測していたんですが、さすがにそこまでは届いていません。それでも、AES-NIが無効な場合の計測値と比較すると、2倍強の性能差が出ています。AES-NIの効果はやはり大きいと言えます。

cryptsetup benchmark」コマンドのベンチマーク計測処理はメモリ上でのみ実行されるのに対して、上表はディスクの読み書き処理を伴った計測値です。AES-NIの性能がいかに優れていても、ディスクのI/O性能に引きずられることでこのような結果になるのかもしれません。DE3815TYKHEに組み込んでいるSATAディスクはIntel 320 Series 80GB SSDですが、これは3世代位前のSSDで、シーケンシャル・リード270MB/s、シーケンシャル・ライト90MB/sという性能です。最新の高性能なSSDを使えば、もう少し優秀な計測結果が得られるのではないかと思います。また、DE3815TYKHEに搭載されているE3815はシングルコアのプロセッサです。2コアのE3826/3827や4コアのE3845なら、ディスク読み書きや暗号処理がマルチスレッドで実行されるので、さらに性能は向上するはずです。

【2015/01/06 追記】

本記事の作業は、Poky + Valley Island BSP Daisy 1.6.2を使ってビルドしたcore-image-satoイメージを使っています。ターゲットはいつものとおりDE3815TYKHEです(いまのところ、E38xxx搭載ターゲットはこれしか持っていません)。上記の計測に使用したDE3815TYKHEの基本スペックを示しておきます。
  • CPU Intel(R) Atom(TM) Processor E3815 (512K Cache,1.46 GHz,1コア)
  • メモリ PC3L-12800(DDR3L-1600)2GB
  • ディスク Intel 320 Series 80GB SSD SATA 3Gb/s(シーケンシャル・リード270MB/s,シーケンシャル・ライト90MB/s)

本記事ではcryptsetupのAES-NI対応機能を有効にするための方法だけを記していますが、この解決方法に辿り着くまでの経緯も書いておきます。

じつは、カーネルのコンフィグレーション設定項目CONFIG_CRYPTO_AES_NI_INTELの存在は随分前から知っていました。それでも、cryptsetupのためにこの設定項目を有効にする必要はないと思っていました。その理由は、cryptsetupのレシピが以下のような内容であることを確認済みだったからです。
SUMMARY = "Manage plain dm-crypt and LUKS encrypted volumes"
DESCRIPTION = "Cryptsetup is used to conveniently setup dm-crypt managed \
device-mapper mappings. These include plain dm-crypt volumes and \
LUKS volumes. The difference is that LUKS uses a metadata header \
and can hence offer more features than plain dm-crypt. On the other \
hand, the header is visible and vulnerable to damage."
HOMEPAGE = "http://code.google.com/p/cryptsetup/"
SECTION = "console"
LICENSE = "GPL-2.0-with-OpenSSL-exception"
LIC_FILES_CHKSUM = "file://COPYING;md5=32107dd283b1dfeb66c9b3e6be312326"

DEPENDS = "util-linux lvm2 popt libgcrypt"

SRC_URI = "http://cryptsetup.googlecode.com/files/cryptsetup-${PV}.tar.bz2"
SRC_URI[md5sum] = "cd834da49fbe92dd66df02cc5c61280f"
SRC_URI[sha256sum] = "15723f0198303d4bcb99d480b7a773918e2d319f0348457988c063bdd03e109a"

inherit autotools gettext

# Use openssl because libgcrypt drops root privileges
# if libgcrypt is linked with libcap support
PACKAGECONFIG ??= "openssl"
PACKAGECONFIG[openssl] = "--with-crypto_backend=openssl,,openssl"
PACKAGECONFIG[gcrypt] = "--with-crypto_backend=gcrypt,,libgcrypt"

RRECOMMENDS_${PN} = "kernel-module-aes-generic \
kernel-module-dm-crypt \
kernel-module-md5 \
kernel-module-cbc \
kernel-module-sha256-generic \
"

EXTRA_OECONF = "--enable-static"

ハイライト表示の行に注目してください。この記述によって、cryptsetupをデフォルト状態でビルドすると、そのコンフィグレーション設定に「--with-crypto_backend=openssl」というオプションが適用されます。

このオプションはcryptsetup 1.3.0から追加されたもので、cryptsetupの配布元サイトの以下のページに説明が掲載されています。

 Cryptsetup130 - cryptsetup - Cryptsetup 1.3.0 Release Notes - Setup virtual encryption devices under dm-crypt Linux - Google Project Hosting

cryptsetupは自身では暗号処理機能を持っておらず、その機能は外部のライブラリに依存しています。「--with-crypto_backend=openssl」オプションによって、cryptsetupはOpenSSLの暗号処理機能を利用する形でビルドされます。

12/30の記事に記載したとおり、CONFIG_CRYPTO_AES_NI_INTELを有効にしなくても、OpenSSLのAES-NI対応機能はちゃんと動作していることを確認済みです。そのため、OpenSSLのライブラリに依存しているcryptsetupの暗号処理もAES-NI対応機能は有効なはずだと思い込んでいました。

ところが、実際にcryptsetupの暗号処理の性能を計測すると、AES-NI対応機能が有効になっているとは思えない計測値が得られました。もしかすると、上記のオプションが適用されていない状態でcryptsetupがビルドされているんじゃないかという疑いも持ちましたが、以下のコマンドの実行結果により、その疑惑は否定されました。
# cryptsetup benchmark --debug
# cryptsetup 1.6.2 processing "cryptsetup benchmark --debug"
# Running command benchmark.
# Installing SIGINT/SIGTERM handler.
# Unblocking interruption on signal.
# Tests are approximate using memory only (no storage IO).
# Crypto backend (OpenSSL 1.0.1j 15 Oct 2014) initialized.
# KDF pbkdf2, hash sha1: 378820 iterations per second.
PBKDF2-sha1 378820 iterations per second
# Crypto backend (OpenSSL 1.0.1j 15 Oct 2014) initialized.
# KDF pbkdf2, hash sha256: 235317 iterations per second.
PBKDF2-sha256 235317 iterations per second
# Crypto backend (OpenSSL 1.0.1j 15 Oct 2014) initialized.
# KDF pbkdf2, hash sha512: 186712 iterations per second.
PBKDF2-sha512 186712 iterations per second
# Crypto backend (OpenSSL 1.0.1j 15 Oct 2014) initialized.
# KDF pbkdf2, hash ripemd160: 298229 iterations per second.
PBKDF2-ripemd160 298229 iterations per second
# Crypto backend (OpenSSL 1.0.1j 15 Oct 2014) initialized.
# KDF pbkdf2, hash whirlpool: 109226 iterations per second.
PBKDF2-whirlpool 109226 iterations per second
# Crypto backend (OpenSSL 1.0.1j 15 Oct 2014) initialized.
# Algorithm | Key | Encryption | Decryption
aes-cbc 128b 47.9 MiB/s 57.5 MiB/s
# Crypto backend (OpenSSL 1.0.1j 15 Oct 2014) initialized.
serpent-cbc 128b 23.2 MiB/s 24.7 MiB/s
# Crypto backend (OpenSSL 1.0.1j 15 Oct 2014) initialized.
twofish-cbc 128b 45.0 MiB/s 53.7 MiB/s
# Crypto backend (OpenSSL 1.0.1j 15 Oct 2014) initialized.
aes-cbc 256b 38.6 MiB/s 43.8 MiB/s
# Crypto backend (OpenSSL 1.0.1j 15 Oct 2014) initialized.
serpent-cbc 256b 23.3 MiB/s 24.8 MiB/s
# Crypto backend (OpenSSL 1.0.1j 15 Oct 2014) initialized.
twofish-cbc 256b 45.0 MiB/s 53.8 MiB/s
# Crypto backend (OpenSSL 1.0.1j 15 Oct 2014) initialized.
aes-xts 256b 57.5 MiB/s 58.5 MiB/s
# Crypto backend (OpenSSL 1.0.1j 15 Oct 2014) initialized.
serpent-xts 256b 25.2 MiB/s 25.0 MiB/s
# Crypto backend (OpenSSL 1.0.1j 15 Oct 2014) initialized.
twofish-xts 256b 53.4 MiB/s 54.8 MiB/s
# Crypto backend (OpenSSL 1.0.1j 15 Oct 2014) initialized.
aes-xts 512b 44.5 MiB/s 44.4 MiB/s
# Crypto backend (OpenSSL 1.0.1j 15 Oct 2014) initialized.
serpent-xts 512b 25.3 MiB/s 25.0 MiB/s
# Crypto backend (OpenSSL 1.0.1j 15 Oct 2014) initialized.
twofish-xts 512b 53.4 MiB/s 54.7 MiB/s
Command successful.

--debug」というオプションはcryptsetupのすべての機能に対して働き、cryptsetupの動作時にデバッグ情報を出力してくれます。上のデバッグ情報から、AES暗号処理の実行時にちゃんとOpenSSLの初期化が行われている(多分OpenSSL側のライブラリ・ルーチンの呼び出しも行われている)ということが判ります。

それでは、なぜcryptsetupのAES-NI対応機能は有効に働かないのか。いまだにその原因は判っていませんが、次のような仮説なら立てられるじゃないかと思っています。
  • cryptsetupからのAES暗号処理の呼び出し形式がOpenSSL側のライブラリ・ルーチンと互換性が取れていないため、その処理がエラーになっている。仕方なくcryptsetupはカーネルのAES暗号処理を利用している。

この仮説が正しいかどうかは自信がありません。また、本仮説の証明方法もいまのところ思いつきません。cryptsetupのAES暗号処理のソースコードを解読するしかありませんが、さすがにそこまでする時間はいまは取れません。

ただし、いつかは本問題の原因を究明したいと思っています。上記のcryptsetupのページに "Note that kernel userspace backend is very slow for this type of operation." という記述が存在しています。cryptsetupから呼び出しているOpenSSL側のAES暗号処理がちゅんと有効に働けば、cryptsetupの性能はいまよりさらに向上するのではないかと思えるからです。
posted by とみやん at 17:33| Comment(0) | TrackBack(0) | Embedded Linux > Yocto Project

2015年01月03日

[Yocto] smartmontoolsによるディスク自己診断情報の取得

最近のハードディスクやSSDは自己診断情報を持っていて、一定のアクセス方法に従うと、CPUからこの情報を取得することができます。S.M.A.R.T.(Self-Monitoring, Analysis and Reporting Technology)と呼ばれているものがそれです。

PCに搭載されている最近のBIOSは、起動時のPOST処理実行中にHDD/SSDからS.M.A.R.T. 情報を取得して、問題を検知したらエラーメッセージを表示する機能を備えています。マザーボード・メーカーもHDD診断ソフトを作成して製品の添付CDに収納したりしていますし、フリーのWindows用HDD診断ソフトもいくつか存在します。たとえマイナーな機能のソフトであっても、Windows用が在れば必ずと言って良いほどLinuxでも同種のソフトが存在します(Linux用はオープンソース・ソフトウェアですが)。smartmontoolsというものが在り、これがS.M.A.R.T. 情報を利用したLinux用のHDD診断ソフトとして有名です。

Yocto Linuxにもsmartmontoolsのレシピが存在するので、試しにDE3815TYKHEで使ってみました。bblayers.conflocal.confに以下のような変更を加えれば、core-image-satoイメージにsmartmontoolsを組み込むことができます。
# LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
LCONF_VERSION = "6"

BBPATH = "${TOPDIR}"
BBFILES ?= ""

BBLAYERS ?= " \
/home/yuhri/Yocto/poky-daisy-11.0.2/meta \
/home/yuhri/Yocto/poky-daisy-11.0.2/meta-yocto \
/home/yuhri/Yocto/poky-daisy-11.0.2/meta-yocto-bsp \
/home/yuhri/Yocto/poky-daisy-11.0.2/meta-openembedded/meta-oe \
/home/yuhri/Yocto/poky-daisy-11.0.2/meta-intel \
/home/yuhri/Yocto/poky-daisy-11.0.2/meta-intel/meta-tlk \
/home/yuhri/Yocto/poky-daisy-11.0.2/meta-de3815tybe \
"
BBLAYERS_NON_REMOVABLE ?= " \
/home/yuhri/Yocto/poky-daisy-11.0.2/meta \
/home/yuhri/Yocto/poky-daisy-11.0.2/meta-yocto \
"

#
# Additional packages to be installed to the specific images
#
IMAGE_INSTALL_append_pn-core-image-sato = " \
parted \
hdparm \
cryptsetup \
smartmontools"

ただし、前記事で紹介したcryptsetupと同様に、smartmontoolsのレシピはmeta-openembeddedリポジトリの方に収集されているので、あらかじめ同リポジトリのパッケージレシピを取得しておく必要があります。〔2014/12/14の記事を参照

HDD/SSDのS.M.A.R.T. 情報を調べるには、smartmontoolsパッケージに含まれる「smartctl」というコマンドを使います。

最初にディスクを検索したければ、「--scan」オプションを使ってできるようです。
# smartctl --scan
/dev/sda -d scsi # /dev/sda, SCSI device

「-i」オプションによって、指定したデバイスがS.M.A.R.T.に対応しているかどうかを確認できます。
# smartctl -i /dev/sda
smartctl 6.2 2013-07-26 r3841 [x86_64-linux-3.10.59-ltsi-yocto-standard] (local build)
Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family: Intel 320 Series SSDs
Device Model: INTEL SSDSA2CW080G3
Serial Number: CVPR13710AME080BGN
LU WWN Device Id: 5 001517 9596a5d21
Firmware Version: 4PC10362
User Capacity: 80,026,361,856 bytes [80.0 GB]
Sector Size: 512 bytes logical/physical
Rotation Rate: Solid State Device
Device is: In smartctl database [for details use: -P show]
ATA Version is: ATA8-ACS T13/1699-D revision 4
SATA Version is: SATA 2.6, 3.0 Gb/s
Local Time is: Sun Jan 4 00:58:30 2015 UTC
SMART support is: Available - device has SMART capability.
SMART support is: Enabled


対象デバイスの自己診断情報を取得するには、「-a」まはた「-x」オプションを使います。前者がS.M.A.R.T.から取得可能な全情報を、後者はS.M.A.R.T.以外の情報も表示します。
# smartctl -a /dev/sda
smartctl 6.2 2013-07-26 r3841 [x86_64-linux-3.10.59-ltsi-yocto-standard] (local build)
Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family: Intel 320 Series SSDs
Device Model: INTEL SSDSA2CW080G3
Serial Number: CVPR13710AME080BGN
LU WWN Device Id: 5 001517 9596a5d21
Firmware Version: 4PC10362
User Capacity: 80,026,361,856 bytes [80.0 GB]
Sector Size: 512 bytes logical/physical
Rotation Rate: Solid State Device
Device is: In smartctl database [for details use: -P show]
ATA Version is: ATA8-ACS T13/1699-D revision 4
SATA Version is: SATA 2.6, 3.0 Gb/s
Local Time is: Sun Jan 4 00:13:09 2015 UTC
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status: (0x00) Offline data collection activity
was never started.
Auto Offline Data Collection: Disabled.
Self-test execution status: ( 0) The previous self-test routine completed
without error or no self-test has ever
been run.
Total time to complete Offline
data collection: ( 1) seconds.
Offline data collection
capabilities: (0x75) SMART execute Offline immediate.
No Auto Offline data collection support.
Abort Offline collection upon new
command.
No Offline surface scan supported.
Self-test supported.
Conveyance Self-test supported.
Selective Self-test supported.
SMART capabilities: (0x0003) Saves SMART data before entering
power-saving mode.
Supports SMART auto save timer.
Error logging capability: (0x01) Error logging supported.
General Purpose Logging supported.
Short self-test routine
recommended polling time: ( 1) minutes.
Extended self-test routine
recommended polling time: ( 1) minutes.
Conveyance self-test routine
recommended polling time: ( 1) minutes.
SCT capabilities: (0x003d) SCT Status supported.
SCT Error Recovery Control supported.
SCT Feature Control supported.
SCT Data Table supported.

SMART Attributes Data Structure revision number: 5
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
3 Spin_Up_Time 0x0020 100 100 000 Old_age Offline - 0
4 Start_Stop_Count 0x0030 100 100 000 Old_age Offline - 0
5 Reallocated_Sector_Ct 0x0032 100 100 000 Old_age Always - 0
9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 917
12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 1164
170 Reserve_Block_Count 0x0033 100 100 010 Pre-fail Always - 0
171 Program_Fail_Count 0x0032 100 100 000 Old_age Always - 0
172 Erase_Fail_Count 0x0032 100 100 000 Old_age Always - 0
183 Runtime_Bad_Block 0x0030 100 100 000 Old_age Offline - 7522
184 End-to-End_Error 0x0032 100 100 090 Old_age Always - 0
187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0
192 Unsafe_Shutdown_Count 0x0032 100 100 000 Old_age Always - 120
199 UDMA_CRC_Error_Count 0x0030 100 100 000 Old_age Offline - 0
225 Host_Writes_32MiB 0x0032 100 100 000 Old_age Always - 136685
226 Workld_Media_Wear_Indic 0x0032 100 100 000 Old_age Always - 1515
227 Workld_Host_Reads_Perc 0x0032 100 100 000 Old_age Always - 77
228 Workload_Minutes 0x0032 100 100 000 Old_age Always - 55045
232 Available_Reservd_Space 0x0033 100 100 010 Pre-fail Always - 0
233 Media_Wearout_Indicator 0x0032 099 099 000 Old_age Always - 0
241 Host_Writes_32MiB 0x0032 100 100 000 Old_age Always - 136685
242 Host_Reads_32MiB 0x0032 100 100 000 Old_age Always - 459867

SMART Error Log Version: 1
No Errors Logged

SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Vendor (0xeb) Completed without error 00% 917 -

SMART Selective self-test log data structure revision number 0
Note: revision number not 1 implies that no selective self-test has ever been run
SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
1 0 0 Not_testing
2 0 0 Not_testing
3 0 0 Not_testing
4 0 0 Not_testing
5 0 0 Not_testing
Selective self-test flags (0x0):
After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.


# smartctl -x /dev/sda
smartctl 6.2 2013-07-26 r3841 [x86_64-linux-3.10.59-ltsi-yocto-standard] (local build)
Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family: Intel 320 Series SSDs
Device Model: INTEL SSDSA2CW080G3
Serial Number: CVPR13710AME080BGN
LU WWN Device Id: 5 001517 9596a5d21
Firmware Version: 4PC10362
User Capacity: 80,026,361,856 bytes [80.0 GB]
Sector Size: 512 bytes logical/physical
Rotation Rate: Solid State Device
Device is: In smartctl database [for details use: -P show]
ATA Version is: ATA8-ACS T13/1699-D revision 4
SATA Version is: SATA 2.6, 3.0 Gb/s
Local Time is: Sun Jan 4 00:13:13 2015 UTC
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
AAM feature is: Unavailable
APM feature is: Unavailable
Rd look-ahead is: Enabled
Write cache is: Enabled
ATA Security is: Disabled, frozen [SEC2]
Unexpected SCT status 0x0002 (action_code=4, function_code=2)
Wt Cache Reorder: N/A

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status: (0x00) Offline data collection activity
was never started.
Auto Offline Data Collection: Disabled.
Self-test execution status: ( 0) The previous self-test routine completed
without error or no self-test has ever
been run.
Total time to complete Offline
data collection: ( 1) seconds.
Offline data collection
capabilities: (0x75) SMART execute Offline immediate.
No Auto Offline data collection support.
Abort Offline collection upon new
command.
No Offline surface scan supported.
Self-test supported.
Conveyance Self-test supported.
Selective Self-test supported.
SMART capabilities: (0x0003) Saves SMART data before entering
power-saving mode.
Supports SMART auto save timer.
Error logging capability: (0x01) Error logging supported.
General Purpose Logging supported.
Short self-test routine
recommended polling time: ( 1) minutes.
Extended self-test routine
recommended polling time: ( 1) minutes.
Conveyance self-test routine
recommended polling time: ( 1) minutes.
SCT capabilities: (0x003d) SCT Status supported.
SCT Error Recovery Control supported.
SCT Feature Control supported.
SCT Data Table supported.

SMART Attributes Data Structure revision number: 5
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAGS VALUE WORST THRESH FAIL RAW_VALUE
3 Spin_Up_Time -----K 100 100 000 - 0
4 Start_Stop_Count ----CK 100 100 000 - 0
5 Reallocated_Sector_Ct -O--CK 100 100 000 - 0
9 Power_On_Hours -O--CK 100 100 000 - 917
12 Power_Cycle_Count -O--CK 100 100 000 - 1164
170 Reserve_Block_Count PO--CK 100 100 010 - 0
171 Program_Fail_Count -O--CK 100 100 000 - 0
172 Erase_Fail_Count -O--CK 100 100 000 - 0
183 Runtime_Bad_Block ----CK 100 100 000 - 7522
184 End-to-End_Error -O--CK 100 100 090 - 0
187 Reported_Uncorrect -O--CK 100 100 000 - 0
192 Unsafe_Shutdown_Count -O--CK 100 100 000 - 120
199 UDMA_CRC_Error_Count ----CK 100 100 000 - 0
225 Host_Writes_32MiB -O--CK 100 100 000 - 136685
226 Workld_Media_Wear_Indic -O--CK 100 100 000 - 1515
227 Workld_Host_Reads_Perc -O--CK 100 100 000 - 77
228 Workload_Minutes -O--CK 100 100 000 - 55045
232 Available_Reservd_Space PO--CK 100 100 010 - 0
233 Media_Wearout_Indicator -O--CK 099 099 000 - 0
241 Host_Writes_32MiB -O--CK 100 100 000 - 136685
242 Host_Reads_32MiB -O--CK 100 100 000 - 459867
||||||_ K auto-keep
|||||__ C event count
||||___ R error rate
|||____ S speed/performance
||_____ O updated online
|______ P prefailure warning

Log Directories not read due to '-F nologdir' option

SMART Extended Comprehensive Error Log Version: 1 (2 sectors)
No Errors Logged

SMART Extended Self-test Log Version: 1 (2 sectors)
Invalid Self-test Log index = 0x00eb (reserved = 0x00)
SMART Selective self-test log data structure revision number 0
Note: revision number not 1 implies that no selective self-test has ever been run
SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
1 0 0 Not_testing
2 0 0 Not_testing
3 0 0 Not_testing
4 0 0 Not_testing
5 0 0 Not_testing
Selective self-test flags (0x0):
After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.

Read SCT Data Table failed: scsi error aborted command
Read SCT Temperature History failed

SCT Error Recovery Control:
Read: Disabled
Write: Disabled

Device Statistics (GP Log 0x04)
Page Offset Size Value Description
1 ===== = = == General Statistics (rev 2) ==
1 0x008 4 1164 Lifetime Power-On Resets
1 0x010 4 917 Power-on Hours
1 0x018 6 8957811011 Logical Sectors Written
1 0x020 6 162155053 Number of Write Commands
1 0x028 6 30137881911 Logical Sectors Read
1 0x030 6 780175533 Number of Read Commands
4 ===== = = == General Errors Statistics (rev 1) ==
4 0x008 4 0 Number of Reported Uncorrectable Errors
4 0x010 4 0 Resets Between Cmd Acceptance and Completion
6 ===== = = == Transport Statistics (rev 1) ==
6 0x008 4 4433 Number of Hardware Resets
6 0x010 4 16383291 Number of ASR Events
6 0x018 4 0 Number of Interface CRC Errors
7 ===== = = == Solid State Device Statistics (rev 1) ==
7 0x008 1 1 Percentage Used Endurance Indicator

SATA Phy Event Counters (GP Log 0x11)
ID Size Value Description
0x0001 4 0 Command failed due to ICRC error
0x0004 4 0 R_ERR response for host-to-device data FIS
0x0007 4 0 R_ERR response for host-to-device non-data FIS
0x0008 4 0 Device-to-host non-data FIS retries
0x0009 4 5 Transition from drive PhyRdy to drive PhyNRdy
0x000a 4 6 Device-to-host register FISes sent due to a COMRESET
0x000b 4 0 CRC errors within host-to-device FIS
0x000d 4 0 Non-CRC errors within host-to-device FIS
0x000f 4 0 R_ERR response for host-to-device data FIS, CRC
0x0010 4 0 R_ERR response for host-to-device data FIS, non-CRC
0x0012 4 0 R_ERR response for host-to-device non-data FIS, CRC
0x0013 4 0 R_ERR response for host-to-device non-data FIS, non-CRC


どちらも難しそうな単語と数値の羅列ですね。S.M.A.R.T.情報はハードディスクの構造や動作に直結している低レベルなデータなので、これらのデータからHDD/SSDの状態を把握するのはかなり困難だと思います。

【参考ページ】

 FreeBSDでsmartmontoolsのインストール | Nobwak's Lair
 SMART:smartmontoolsでハードディスク診断
 S.M.A.R.T. (日本語) - ArchWiki
posted by とみやん at 23:05| Comment(0) | TrackBack(0) | Embedded Linux > Yocto Project

2015年01月02日

[Yocto] 暗号化ファイルシステムLUKSを使ってみた

企業内では、PCにディスク暗号化ソフトを導入して、内蔵ディスクや外付メディア全体に暗号処理を施した状態で使うことが良くあります。セキュリティ上の観点から、PC本体や外付メディアが盗難に遭っても、それらの中に格納されているファイルを読めなくすることが目的です。また、社員がUSBメディアなどを外に持ち出したときに紛失するケースなども想定しているのでしょう。いままで私が働いたことがある会社でも、暗号化ソフトを導入せずにPCを使うことを禁止している所がいくつかありました。こういう堅苦しいルールを設けているのは大抵は日本国内の大手企業だけです。外資系やベンチャー企業にはこういうルールはまずありません。暗号化ソフトを導入すると当然ディスク性能が低下し、アプリの起動やファイルの読み書きに時間がかかるようになるので作業効率が低下します。日本の大手企業は作業効率よりセキュリティを優先するのに対して、ベンチャー企業はセキュリティより作業効率を優先する所が多いです。私は外資系やベンチャー企業でも働いたことがありますが、これらの企業でPCへ暗号化ソフトを導入することを義務化している所は一つもありませんでした。現状企業内のPCから情報が漏洩するケースはインターネット経由がほとんどです。社員の故意または過失によるケースもあるでしょうが、ディスク暗号化ソフトが有益なのは、社員の過失によってディスクメディアが第三者の手に渡ったときだけです(故意の情報漏洩を企む社員なら、ディスク暗号化ソフトを回避するために、持ち込みのディスクを用意したり、スクリプトや常駐ソフトを使ってインターネット経由でデータを漏洩させるなどの方法を取るはずです)。PCの盗難によって情報が漏洩したというケースはあまり聞いたことがありません。結局ディスク暗号化ソフトをPCへ導入することは企業側の自己満足であって、実際にこれが情報漏洩を防ぐようなケースはほとんど存在しないんじゃないかと私は思っています。社員が使う全PCにディスク暗号化ソフトを導入することと、社内のサーバーやゲートウェイなどにセキュリティ対策を施することを比較すると、後者の費用対効果の方が圧倒的に優れています。改めて言いますが、現状企業からの情報漏洩で一番多いケースはインターネット経由です。外資系やベンチャー企業も当然セキュリティを重視していますが、これらの会社は費用対効果を考慮して、現実的なセキュリティ対策を選択している所が多いのが実情です。

冒頭から話が大きく逸れてしまったので元に戻しましょう。日本国内の企業での需要が高いからかWindows用ディスク暗号化ソフトは多くの種類が存在しているようですが、Linuxにも同様のオープンソース・ソフトウェアがいくつか存在します。Linux用の暗号化ファイルシステムとしてもっとも有名なのはLUKS(Linux Unified Key Setup。発音は「ラックス」)というものです。ターゲットシステム上にLUKS暗号化ファイルシステムを作成するには、cryptsetupというパッケージを利用します。本記事に書く内容は、Yocto Linuxのcryptsetupレシピを使ったLUKS暗号化ファイルシステムの評価作業の記録です。

ターゲットとして使ったのはDE3815TYKHEです。DE3815TYKHE用のbblayers.conflocal.confに以下のような変更を加えると、core-image-satoイメージにcryptsetupを組み込むことができます。
# LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
LCONF_VERSION = "6"

BBPATH = "${TOPDIR}"
BBFILES ?= ""

BBLAYERS ?= " \
/home/yuhri/Yocto/poky-daisy-11.0.2/meta \
/home/yuhri/Yocto/poky-daisy-11.0.2/meta-yocto \
/home/yuhri/Yocto/poky-daisy-11.0.2/meta-yocto-bsp \
/home/yuhri/Yocto/poky-daisy-11.0.2/meta-openembedded/meta-oe \
/home/yuhri/Yocto/poky-daisy-11.0.2/meta-intel \
/home/yuhri/Yocto/poky-daisy-11.0.2/meta-intel/meta-tlk \
/home/yuhri/Yocto/poky-daisy-11.0.2/meta-de3815tybe \
"
BBLAYERS_NON_REMOVABLE ?= " \
/home/yuhri/Yocto/poky-daisy-11.0.2/meta \
/home/yuhri/Yocto/poky-daisy-11.0.2/meta-yocto \
"

#
# Additional packages to be installed to the specific images
#
IMAGE_INSTALL_append_pn-core-image-sato = " \
parted \
hdparm \
cryptsetup"

cryptsetupのレシピは、openembedded-coreではなくmeta-openembeddedリポジトリの方に収集されています。そのため、Yocto Linuxの配布パッケージにcryptsetupのレシピは収納されていません。cryptsetupのレシピを利用したい場合は、meta-openembeddedリポジトリのパッケージレシピをgitコマンドで取得しておく必要があります。〔2014/12/14の記事を参照

また、上ではpartedとhdparmパッケージもcore-image-satoイメージへ追加しています。partedは、DE3815TYKHEの内蔵SATAディスク上にLUKSファイルシステム用のパーティションを作成するために使います。hdparmの方は、これを使ってLUKSファイルシステムの読み込み速度の計測を行う目的で組み込んでいます。

■ LUKS用パーティションの確保(Intel E38xx Yocto Linux固有)


bitbakeコマンドによって、partedとcryptsetupを追加したcore-image-satoイメージのhddimgファイルを生成し、そのファイルからYocto LinxのLive USBメディアを作成しました。これはDE3815TYKHEへYocto Linuxをインストールする前のお決まりの手順ですが、その後に、GPartedのLive USBメディアも作成しました。このGPartedとpartedの両方を使って、DE3815TYKHEの内蔵SATA上にLUKSファイルシステム用のパーティション領域を確保します。GPartedとpartedはディスク・パーティションを操作する同種のソフトウェアです。partedが存在するのになぜGPartedが必要になるかというと、Yocto Linxのpartedではなぜか「resize」コマンド(パーティションのサイズを変更するコマンド)が使えないからです。GPartedの方で既存のパーティションをリサイズして空き領域を確保した上で、partedの方でその空き領域上にLUKS用パーティションを作成するというテクニックを使います。DE3815TYKHEの内蔵SATAディスク上にLUKS用パーティションを作成するための具体的な手順を以下に示します。
  1. 上で作成したYocto LinuxのLive USBメディアをUSBポートに挿した状態で、DE3815TYKHEの電源をONにします。

  2. 起動時に表示されるGRUBのメニューから「install」を選択して、DE3815TYKHEの内蔵SATAへYocto Linuxをインストールします。Yocto Linuxのインストールが済んだら(インストール完了時の「Remove your installation media, and press ENTER」というメッセージが表示されたら)、Powerボタンを長押しして、DE3815TYKHEの電源をOFFにします。

  3. USBポートのメディアをGParted Live USBに差し替えてから、DE3815TYKHEの電源をONにします。

  4. GPartedが起動したら、DE3815TYKHEの内蔵SATA上の既存のext3パーティション(/dev/sda2)のサイズを10GB縮小します(同パーティションの後方に10240MiBの空き領域を確保します。空き領域のサイズは任意です)。
    GParted_Live-Resizing_Yocto_ext3_Partition_on_SATA-775x500
    この操作が済んだら、GPartedを終了して、シャットダウンします。

  5. USBポートのメディアをYocto LinuxのLive USBに差し替えてから、DE3815TYKHEの電源をONにします。

  6. 起動時に表示されるGRUBのメニューから「boot」を選択して、Live USBメディアからYocto Linuxを起動します。

  7. ターミナルの画面を開いて、以下の手順を実行します。
    # df
    Filesystem 1K-blocks Used Available Use% Mounted on
    none 964692 4 964688 0% /dev
    /dev/sda1 18378 6410 11968 35% /media/sda1
    /dev/sda2 62736324 411152 59138280 1% /media/sda2
    /dev/sdb 350192 344648 5544 98% /media/sdb
    /dev/loop0 320464 216362 87555 71% /
    tmpfs 40 0 40 0% /mnt/.psplash
    tmpfs 969256 260 968996 0% /run
    tmpfs 969256 168 969088 0% /var/volatile
    # umount /media/sda1
    # umount /media/sda2
    # parted /dev/sda
    GNU Parted 3.1
    Using /dev/sda
    Welcome to GNU Parted! Type 'help' to view a list of commands.
    (parted) print free
    Model: ATA INTEL SSDSA2CW08 (scsi)
    Disk /dev/sda: 80.0GB
    Sector size (logical/physical): 512B/512B
    Partition Table: gpt
    Disk Flags:

    Number Start End Size File system Name Flags
    17.4kB 1049kB 1031kB Free Space
    1 1049kB 19.9MB 18.9MB fat16 primary boot
    2 19.9MB 65.3GB 65.3GB ext3 primary
    65.3GB 76.0GB 10.7GB Free Space
    3 76.0GB 80.0GB 4001MB linux-swap(v1) primary
    80.0GB 80.0GB 73.2kB Free Space

    (parted) rm 3
    (parted) mkpart primary ext2 65.3GB 76.0GB
    (parted) mkpart primary linux-swap 76.0GB 100%
    (parted) print free
    Model: ATA INTEL SSDSA2CW08 (scsi)
    Disk /dev/sda: 80.0GB
    Sector size (logical/physical): 512B/512B
    Partition Table: gpt
    Disk Flags:

    Number Start End Size File system Name Flags
    17.4kB 1049kB 1031kB Free Space
    1 1049kB 19.9MB 18.9MB fat16 primary boot
    2 19.9MB 65.3GB 65.3GB ext3 primary
    3 65.3GB 76.0GB 10.7GB primary
    4 76.0GB 80.0GB 4027MB primary
    80.0GB 80.0GB 73.2kB Free Space

    (parted) quit
    Information: You may need to update /etc/fstab.

    # mkswap /dev/sda4
    Setting up swapspace version 1, size = 4026527744 bytes
    # mount /dev/sda2 /mnt
    # cat /mnt/etc/fstab
    # stock fstab - you probably want to override this with a machine specific one

    /dev/root / auto defaults 1 1
    proc /proc proc defaults 0 0
    devpts /dev/pts devpts mode=0620,gid=5 0 0
    usbdevfs /proc/bus/usb usbdevfs noauto 0 0
    tmpfs /run tmpfs mode=0755,nodev,nosuid,strictatime 0 0
    tmpfs /var/volatile tmpfs defaults 0 0

    # uncomment this if your device has a SD/MMC/Transflash slot
    #/dev/mmcblk0p1 /media/card auto defaults,sync,noauto 0 0

    /dev/sda3 swap swap defaults 0 0
    # sed -i "s@/dev/sda3@/dev/sda4@" /mnt/etc/fstab
    # cat /mnt/etc/fstab
    # stock fstab - you probably want to override this with a machine specific one

    /dev/root / auto defaults 1 1
    proc /proc proc defaults 0 0
    devpts /dev/pts devpts mode=0620,gid=5 0 0
    usbdevfs /proc/bus/usb usbdevfs noauto 0 0
    tmpfs /run tmpfs mode=0755,nodev,nosuid,strictatime 0 0
    tmpfs /var/volatile tmpfs defaults 0 0

    # uncomment this if your device has a SD/MMC/Transflash slot
    #/dev/mmcblk0p1 /media/card auto defaults,sync,noauto 0 0

    /dev/sda4 swap swap defaults 0 0
    # umount /mnt
    # sync

DE3815TYKHEのマザーボード上にはSATAコネクタが1つしか存在しておらず、これは内蔵SATAディスクで使われています。複数のSATAコネクタが在れば、2台目のSATAディスクを接続して、そちらにLUKS用パーティションを作成できるのですが、DE3815TYKHEではそれができません。そのため、上のようなテクニックを使って内蔵SATAディスク上にLUKS用パーティションを確保している訳です。もちろんUSBメディア上にLUKS用パーティションを作成することも可能です。しかし、その場合、LUKSファイルシステムの読み書き速度はUSBメディアの性能に大きく依存してしまいます。USBメディアの読み書き速度はメーカーによって結構バラツキがあるので、比較的読み書き速度のバラツキが小さくより高速なSATAディスクを使いたかったのです。LUKSファイルシステムの読み書き速度の計測をやってみたかったことが、USBメディアではなくSATAディスクを選んだ理由です。

■ LUKSファイルシステムの作成


これでLUKSファイルシステムを使うための準備が整ったので、 さっそくcryptsetupコマンドを使ってLUKSファイルシステムを作成してみましょう。なお、以降の操作は、Yocto LinuxをDE3815TYKHEの内蔵SATAディスクから起動した状態で行っています。

最初に、cryptsetupコマンド のヘルプ情報を表示させてみました。
# cryptsetup --help
cryptsetup 1.6.2
Usage: cryptsetup [OPTION...] <action> <action-specific>
--version Print package version
-v, --verbose Shows more detailed error messages
--debug Show debug messages
-c, --cipher=STRING The cipher used to encrypt the disk (see /proc/crypto)
-h, --hash=STRING The hash used to create the encryption key from the passphrase
-y, --verify-passphrase Verifies the passphrase by asking for it twice
-d, --key-file=STRING Read the key from a file.
--master-key-file=STRING Read the volume (master) key from file.
--dump-master-key Dump volume (master) key instead of keyslots info.
-s, --key-size=BITS The size of the encryption key
-l, --keyfile-size=bytes Limits the read from keyfile
--keyfile-offset=bytes Number of bytes to skip in keyfile
--new-keyfile-size=bytes Limits the read from newly added keyfile
--new-keyfile-offset=bytes Number of bytes to skip in newly added keyfile
-S, --key-slot=INT Slot number for new key (default is first free)
-b, --size=SECTORS The size of the device
-o, --offset=SECTORS The start offset in the backend device
-p, --skip=SECTORS How many sectors of the encrypted data to skip at the beginning
-r, --readonly Create a readonly mapping
-i, --iter-time=msecs PBKDF2 iteration time for LUKS (in ms)
-q, --batch-mode Do not ask for confirmation
-t, --timeout=secs Timeout for interactive passphrase prompt (in seconds)
-T, --tries=INT How often the input of the passphrase can be retried
--align-payload=SECTORS Align payload at <n> sector boundaries - for luksFormat
--header-backup-file=STRING File with LUKS header and keyslots backup.
--use-random Use /dev/random for generating volume key.
--use-urandom Use /dev/urandom for generating volume key.
--shared Share device with another non-overlapping crypt segment.
--uuid=STRING UUID for device to use.
--allow-discards Allow discards (aka TRIM) requests for device.
--header=STRING Device or file with separated LUKS header.
--test-passphrase Do not activate device, just check passphrase.
--tcrypt-hidden Use hidden header (hidden TCRYPT device).
--tcrypt-system Device is system TCRYPT drive (with bootloader).
-M, --type=STRING Type of device metadata: luks, plain, loopaes, tcrypt.
--force-password Disable password quality check (if enabled).

Help options:
-?, --help Show this help message
--usage Display brief usage

<action> is one of:
open <device> [--type <type>] [<name>] - open device as mapping <name>
close <name> - close device (remove mapping)
resize <name> - resize active device
status <name> - show device status
benchmark <name> - benchmark cipher
repair <device> - try to repair on-disk metadata
luksFormat <device> [<new key file>] - formats a LUKS device
luksAddKey <device> [<new key file>] - add key to LUKS device
luksRemoveKey <device> [<key file>] - removes supplied key or key file from LUKS device
luksChangeKey <device> [<key file>] - changes supplied key or key file of LUKS device
luksKillSlot <device> <key slot> - wipes key with number <key slot> from LUKS device
luksUUID <device> - print UUID of LUKS device
isLuks <device> - tests <device> for LUKS partition header
luksDump <device> - dump LUKS partition information
tcryptDump <device> - dump TCRYPT device information
luksSuspend <device> - Suspend LUKS device and wipe key (all IOs are frozen).
luksResume <device> - Resume suspended LUKS device.
luksHeaderBackup <device> - Backup LUKS device header and keyslots
luksHeaderRestore <device> - Restore LUKS device header and keyslots

You can also use old <action> syntax aliases:
open: create (plainOpen), luksOpen, loopaesOpen, tcryptOpen
close: remove (plainClose), luksClose, loopaesClose, tcryptClose

<name> is the device to create under /dev/mapper
<device> is the encrypted device
<key slot> is the LUKS key slot number to modify
<key file> optional key file for the new key for luksAddKey action

Default compiled-in key and passphrase parameters:
Maximum keyfile size: 8192kB, Maximum interactive passphrase length 512 (characters)
Default PBKDF2 iteration time for LUKS: 1000 (ms)

Default compiled-in device cipher parameters:
loop-AES: aes, Key 256 bits
plain: aes-cbc-essiv:sha256, Key: 256 bits, Password hashing: ripemd160
LUKS1: aes-xts-plain64, Key: 256 bits, LUKS header hashing: sha1, RNG: /dev/urandom

親切なヘルプ情報なので、cryptsetupコマンドのほとんどの操作はこのヘルプ情報を見ながらできるんじゃないかと思います。なお、ググれば、cryptsetupコマンドの詳細情報は結構見つかります。

それでは、前述の操作によって確保したパーティション/dev/sda3をLUKSパーティションに設定してみましょう。以下のコマンドによって、それができます。
# parted /dev/sda print free
Model: ATA INTEL SSDSA2CW08 (scsi)
Disk /dev/sda: 80.0GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number Start End Size File system Name Flags
17.4kB 1049kB 1031kB Free Space
1 1049kB 19.9MB 18.9MB fat16 primary boot
2 19.9MB 65.3GB 65.3GB ext3 primary
3 65.3GB 76.0GB 10.7GB primary
4 76.0GB 80.0GB 4027MB linux-swap(v1) primary
80.0GB 80.0GB 73.2kB Free Space

# cryptsetup luksFormat /dev/sda3

WARNING!
========
This will overwrite data on /dev/sda3 irrevocably.

Are you sure? (Type uppercase yes): YES
Enter passphrase: 〔← 任意のパスフレーズを入力する〕
Verify passphrase: 〔← 上と同じパスフレーズを入力する〕

上の「cryptsetup luksFormat」コマンドに「-c」や「-s」オプションを付加すると、暗号化の方式や鍵のビット長などを変更することができます。luksFormatに適用されるこれらのデフォルト設定値は、cryptsetupコマンドのヘルプ情報の「Default compiled-in key and passphrase parameters: ... LUKS1: ...」という部分に表示されています。

上で作成したLUKS用パーティションをファイルシステムとしてフォーマットするには、以下のようなコマンドを使います。
# cryptsetup luksOpen /dev/sda3 luks
Enter passphrase for /dev/sda3: 〔← LUKSパーティション設定時のパスフレーズを入力する〕
# ls -l /dev/mapper
crw------- 1 root root 10, 236 Jan 2 16:14 control
brw------- 1 root root 253, 0 Jan 2 16:21 luks
# mkfs.ext3 /dev/mapper/luks
mke2fs 1.42.9 (28-Dec-2013)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
654080 inodes, 2614784 blocks
130739 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=2680160256
80 block groups
32768 blocks per group, 32768 fragments per group
8176 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632

Allocating group tables: done
Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done

# mkdir /mnt/encrypted
# mount -t ext3 /dev/mapper/luks /mnt/encrypted

最初の「cryptsetup luksOpen」はLUKSパーティションをオープンするために必要なコマンドです。このコマンドを実行すると、/dev/mapperディレクトリの中にLUKSのデバイスファイルが作成されます。LUKSのデバイスファイルが作成されれば、それ以降は普通のパーティションと同様に、このデバイスファイルを使ってmkfs.*コマンドによってLUKSパーティション上にファイルシステムを作成したり、mountコマンドによってマウントすることができます。

そして、LUKSデバイスのマウント後は、ファイルの読み書きも普通にできます。
# cd /mnt/encrypted
# ls -l
drwx------ 2 root root 16384 Jan 2 16:22 lost+found
# echo hello > hello.txt
# ls -l
-rw-r--r-- 1 root root 6 Jan 2 16:23 hello.txt
drwx------ 2 root root 16384 Jan 2 16:22 lost+found
# cat hello.txt
hello

LUKSパーティションをアンマウントしたい場合は、以下の手順を実行します。
# cd
# umount /mnt/encrypted
# cryptsetup luksClose luks
# ls -l /dev/mapper
crw------- 1 root root 10, 236 Jan 2 16:14 control

cryptsetup luksClose 」はLUKSパーティションをクローズするために必要なコマンドです。このコマンドを実行すると、/dev/mapperディレクトリの下のLUKSデバイスファイルは削除されます。

■ LUKSパーティションの鍵操作


LUKSパーティションはヘッダ情報というものを持っています。LUKSパーティションのヘッダ情報は、下のコマンドによって確認できます。
# cryptsetup luksDump /dev/sda3
LUKS header information for /dev/sda3

Version: 1
Cipher name: aes
Cipher mode: xts-plain64
Hash spec: sha1
Payload offset: 4096
MK bits: 256
MK digest: 74 cf a9 e4 33 dd b0 f8 3e d7 4f 0f cd e8 44 e4 83 59 59 54
MK salt: d9 b5 02 90 27 4f 74 b0 f6 fa fd 83 d8 d0 98 dc
18 b0 18 bb af 81 62 90 df 20 ca cf d2 af 69 2e
MK iterations: 46250
UUID: 9d42429a-7ca0-4557-891e-9e3529fda5b8

Key Slot 0: ENABLED
Iterations: 186045
Salt: b8 b3 0a 73 ca 4e 81 39 fe 47 b1 20 ef 61 2b 17
a5 08 f4 5c 62 da 63 07 17 87 b6 53 ad 90 09 7b
Key material offset: 8
AF stripes: 4000
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED

LUKSパーティションの設定時に入力したパスフレーズは、ヘッダ情報内のKey Slot 0に保存されています。

LUKSパーティションのパスフレーズは複数登録できます。新たに登録したパスフレーズは、ヘッダ情報内の最初の空きスロットへ保存されます。
# cryptsetup luksAddKey /dev/sda3
Enter any existing passphrase: 〔← 登録済みのいずれかのパスフレーズを入力する〕
Enter new passphrase for key slot: 〔← 新しいパスフレーズを入力する〕
# cryptsetup luksDump /dev/sda3
LUKS header information for /dev/sda3

Version: 1
Cipher name: aes
Cipher mode: xts-plain64
Hash spec: sha1
Payload offset: 4096
MK bits: 256
MK digest: 74 cf a9 e4 33 dd b0 f8 3e d7 4f 0f cd e8 44 e4 83 59 59 54
MK salt: d9 b5 02 90 27 4f 74 b0 f6 fa fd 83 d8 d0 98 dc
18 b0 18 bb af 81 62 90 df 20 ca cf d2 af 69 2e
MK iterations: 46250
UUID: 9d42429a-7ca0-4557-891e-9e3529fda5b8

Key Slot 0: ENABLED
Iterations: 186045
Salt: b8 b3 0a 73 ca 4e 81 39 fe 47 b1 20 ef 61 2b 17
a5 08 f4 5c 62 da 63 07 17 87 b6 53 ad 90 09 7b
Key material offset: 8
AF stripes: 4000
Key Slot 1: ENABLED
Iterations: 183118
Salt: 1e c2 93 20 66 5d eb 40 d6 00 db 7a 32 bb 61 56
71 10 1f e5 37 c3 ee 70 d9 26 8b 34 cf 93 fd 21
Key material offset: 264
AF stripes: 4000
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED

設定済みのパスフレーズを削除することもできます。
# cryptsetup luksKillSlot /dev/sda3 1
Enter any remaining passphrase: 〔← 削除対象スロット以外のいずれかのパスフレーズを入力する〕
# cryptsetup luksDump /dev/sda3
LUKS header information for /dev/sda3

Version: 1
Cipher name: aes
Cipher mode: xts-plain64
Hash spec: sha1
Payload offset: 4096
MK bits: 256
MK digest: 74 cf a9 e4 33 dd b0 f8 3e d7 4f 0f cd e8 44 e4 83 59 59 54
MK salt: d9 b5 02 90 27 4f 74 b0 f6 fa fd 83 d8 d0 98 dc
18 b0 18 bb af 81 62 90 df 20 ca cf d2 af 69 2e
MK iterations: 46250
UUID: 9d42429a-7ca0-4557-891e-9e3529fda5b8

Key Slot 0: ENABLED
Iterations: 186045
Salt: b8 b3 0a 73 ca 4e 81 39 fe 47 b1 20 ef 61 2b 17
a5 08 f4 5c 62 da 63 07 17 87 b6 53 ad 90 09 7b
Key material offset: 8
AF stripes: 4000
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED

また、キー・ファイルを作成して、それをLUKSパーティションのパスフレーズの代わりに登録することができます。
# dd if=/dev/urandom of=/etc/luks_key bs=1 count=1024
1024+0 records in
1024+0 records out
# cryptsetup luksAddKey /dev/sda3 /etc/luks_key
Enter any passphrase: 〔← 登録済みのいずれかのパスフレーズを入力する〕
# cryptsetup luksDump /dev/sda3
LUKS header information for /dev/sda3

Version: 1
Cipher name: aes
Cipher mode: xts-plain64
Hash spec: sha1
Payload offset: 4096
MK bits: 256
MK digest: 74 cf a9 e4 33 dd b0 f8 3e d7 4f 0f cd e8 44 e4 83 59 59 54
MK salt: d9 b5 02 90 27 4f 74 b0 f6 fa fd 83 d8 d0 98 dc
18 b0 18 bb af 81 62 90 df 20 ca cf d2 af 69 2e
MK iterations: 46250
UUID: 9d42429a-7ca0-4557-891e-9e3529fda5b8

Key Slot 0: ENABLED
Iterations: 186045
Salt: b8 b3 0a 73 ca 4e 81 39 fe 47 b1 20 ef 61 2b 17
a5 08 f4 5c 62 da 63 07 17 87 b6 53 ad 90 09 7b
Key material offset: 8
AF stripes: 4000
Key Slot 1: ENABLED
Iterations: 183118
Salt: a5 64 bf dd 2a 0d 09 b6 41 c2 42 1e 6c 1d 23 a2
c3 bd 47 e8 da fb fa b8 70 fb b0 70 87 bc d0 46
Key material offset: 264
AF stripes: 4000
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED

キー・ファイルを登録した場合は、そのキー・ファイルを指定してLUKSパーティションをオープンできます。
# cryptsetup luksOpen /dev/sda3 luks --key-file=/etc/luks_key
# mount -t ext3 /dev/mapper/luks /mnt/encrypted
# ls -l /mnt/encrypted
-rw-r--r-- 1 root root 6 Jan 2 16:23 hello.txt
drwx------ 2 root root 16384 Jan 2 16:22 lost+found
# cat /mnt/encrypted/hello.txt
hello

この場合、パスフレーズの入力は求められません。キー・ファイルがパスフレーズとして扱われるからです。

■ LUKSファイルシステムの性能評価


実際にcryptsetupでLUKS暗号化ファイルシステムを使ってみた感想ですが、非常に良く出来ている優れ物のソフトウェアだと思います。ググってみると、cryptsetupとLUKSに関する多くの情報がヒットするので、これらはかなり広く使われているのでしょう。このように普及しているソフトウェアだと、どれ位の性能を持っているのかがすごく気になります。そこで、LUKSファイルシステムの読み書き速度の計測をやってみました。

LUKSファイルシステムの読み込み速度の計測は、次のコマンドを使って行いました。
# hdparm -t /dev/mapper/luks

書き込み速度の方は、次のコマンドを使って計測しました。
# sync;time bash -c "(dd if=/dev/zero of=/mnt/encrypted/bf bs=8k count=500000; sync)"

このコマンドの実行後に、 毎回Ctrl+c と 「rm /mnt/encrypted/bf」を実行しています。

LUKSファイルシステムの読み書き速度の計測結果は以下のようになりました。上記のコマンドによる計測をそれぞれ3回ずつ行って、もっとも良い値を採用しました。

ファイルシステム読み込み速度(MB/sec)比率書き込み速度(MB/sec)比率
素のext3263.3694.96
LUKS ext341.120.1542.400.44

比較のために、LUKSを設定せず通常のext3でフォーマットしたファイルシステムを使ったケースの計測値も示しています。

上表の2種類の計測値の差がちょっと大きすぎる気がします。Intel E38xxxにはAES-NIが搭載されているので、もっと高い性能が出るはずだと予測していました。ググってみると、AES-NIが有効なケースで、LUKSファイルシステムでも100〜200MB/sec程度の読み込み速度計測値が掲載されているページがいくつか見つかりました。もしかすると、cryptsetupの暗号処理でAES-NIが使われていないのかもしれません。本件については現在調査中です。

【2015/01/05 追記】

Yocto Linux(正確には、OpenEmbeddedリポジトリですが)のcryptsetupに関する重要なTips情報を書くのを忘れていました。

デフォルト状態のValley Island BSPを使ってビルドしたイメージにcryptsetupを組み込むと、「cryptsetup luksFormat <device>」コマンドの実行時に以下のようなエラーに遭遇します。
# cryptsetup luksFormat /dev/sda3

WARNING!
========
This will overwrite data on /dev/sda3 irrevocably.

Are you sure? (Type uppercase yes): YES
Enter passphrase:
Verify passphrase:
device-mapper: reload ioctl on failed: No such file or directory
Failed to open temporary keystore device.
device-mapper: remove ioctl on temporary-cryptsetup-664 failed: No such device or address
device-mapper: reload ioctl on temporary-cryptsetup-664 failed: No such device or address
device-mapper: remove ioctl on temporary-cryptsetup-664 failed: No such device or address
device-mapper: remove ioctl on temporary-cryptsetup-664 failed: No such device or address
device-mapper: remove ioctl on temporary-cryptsetup-664 failed: No such device or address
device-mapper: remove ioctl on temporary-cryptsetup-664 failed: No such device or address

このエラーを解決するには、カーネルの以下の2つのコンフィグレーション設定項目を有効にしてください。
CONFIG_CRYPTO_XTS

-*- Cryptographic API --->
*** Block modes ***
<M> XTS support

CONFIG_CRYPTO_USER_API_SKCIPHER

-*- Cryptographic API --->
*** Random Number Generation ***
<M> User-space interface for symmetric key cipher algorithms

どちらもカーネルがサポートしている暗号処理機能ですが、Valley Island BSPのカーネル設定ではいずれもデフォルト状態で無効になっています。

「cryptsetup benchmark」というコマンドを利用して、上記のカーネルのコンフィグレーション設定項目が有効になっているかどうかを確認することもできます。どちらの設定項目も有効な場合、本コマンドの実行結果は以下のようになります。
# cryptsetup benchmark
# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1 377729 iterations per second
PBKDF2-sha256 236165 iterations per second
PBKDF2-sha512 186712 iterations per second
PBKDF2-ripemd160 298229 iterations per second
PBKDF2-whirlpool 109044 iterations per second
# Algorithm | Key | Encryption | Decryption
aes-cbc 128b 48.0 MiB/s 57.4 MiB/s
serpent-cbc 128b 23.3 MiB/s 24.7 MiB/s
twofish-cbc 128b 45.1 MiB/s 53.9 MiB/s
aes-cbc 256b 38.6 MiB/s 43.8 MiB/s
serpent-cbc 256b 23.3 MiB/s 24.8 MiB/s
twofish-cbc 256b 45.1 MiB/s 53.9 MiB/s
aes-xts 256b 57.6 MiB/s 58.5 MiB/s
serpent-xts 256b 25.3 MiB/s 25.0 MiB/s
twofish-xts 256b 53.4 MiB/s 54.8 MiB/s
aes-xts 512b 44.4 MiB/s 44.4 MiB/s
serpent-xts 512b 25.3 MiB/s 25.0 MiB/s
twofish-xts 512b 53.4 MiB/s 54.8 MiB/s

上記の両方の設定項目が無効な場合、「cryptsetup benchmark」コマンドの実行結果は以下のようになります。
# cryptsetup benchmark
# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1 378274 iterations per second
PBKDF2-sha256 236592 iterations per second
PBKDF2-sha512 185129 iterations per second
PBKDF2-ripemd160 297215 iterations per second
PBKDF2-whirlpool 109226 iterations per second
Required kernel crypto interface not available.
Ensure you have algif_skcipher kernel module loaded.

CONFIG_CRYPTO_USER_API_SKCIPHERがcryptsetupの*-cbcで、CONFIG_CRYPTO_XTSの方が*-xtsで使われる暗号処理機能です。cryptsetupのluksFormatに適用されるデフォルトの暗号パラメータは「aes-xts-plain64, Key: 256 bits」になっています。本エラーが発生する原因は、CONFIG_CRYPTO_XTSによって有効になる暗号処理機能がカーネル側に存在していないからです。

本エラーを解決するにあたって、共通鍵暗号処理について少し調べてみました(数学知識を持たない素人の理解なので、以降の内容が正確どうかは保証しません)。共通鍵暗号処理というのは、暗号化アルゴリズムとブロック操作モードの2つの大きな構成要素によって成り立っているらしいです。上記の件に関連して言うと、AESが暗号化アルゴリズムに、CBC(Cipher-block chaining)やXTS(XEX-based tweaked-codebook mode with ciphertext stealing)がブロック操作モードに相当します(ブロック操作モードはこの2つ以外にもいくつか種類が存在します)。以下のWikipediaページに共通鍵暗号処理のブロック操作モードに関する説明が掲載されているので、詳細が知りたければこれらのページの情報を参照してください。

 Block cipher mode of operation - Wikipedia, the free encyclopedia
 Disk encryption theory - Wikipedia, the free encyclopedia

暗号化ディスクボリュームにおいて使われる共通鍵暗号処理のブロック操作モードを比較すると、CBCよりXTSの方が圧倒的に強度が高いそうです。cryptsetupのluksFormatのデフォルト暗号化パラメータが「aes-xts-plain64, Key: 256 bits」になっているのは、この理由によるのだと思われます。

【参考ページ】

 LUKS(Linux Unified Key Setup)を使ってみる - think-t の晴耕雨読
 (Linux)LUKSでファイルシステムを暗号化してみた : 3流プログラマのメモ書き
 lost and found ( for me ? ): cryptsetup で暗号化ファイルシステムの作成
 dm-crypt/Device encryption - ArchWiki
 hdparm (日本語) - ArchWiki
posted by とみやん at 16:01| Comment(0) | TrackBack(0) | Embedded Linux > Yocto Project

2014年12月30日

[Yocto] Intel E3815でのOpenSSL AES-NI対応機能の性能評価

組込みLinuxでシステムを構築していると、どんなシステムにも必ず入れることになる利用頻度の高いパッケージが存在します。そういうパッケージの一つにOpenSSLというものがあります。OpenSSLとはオープンソースで開発されるSSL/TLSプロトコルを実装したソフトウェアで、通信端末機器には必ずと言って良いほど使われています。Webブラウザで「https:」で始まるURLを入力したときに使われるのがSSL/TLSプロトコルです。企業内のセキュアな電子メール送受信でも本プロトコルが利用されます。OpenSSLはほぼすべてのUnix系OSで採用されていて、Mac OS Xでも使われており、Windows版も存在します。このように広く普及しているため、その脆弱性が問題になることも多いソフトウェアです。

組込みLinuxでもOpenSSLを利用することが非常に多く、インターネット通信機能を持つシステムでは必須のソフトウェアの一つとなっています。Yocto Linuxでも、ほとんどのイメージにOpenSSLが組み込まれています。

SSL/TLSプロトコルには共通鍵暗号という処理が含まれています。同プロトコルの暗号化アルゴリズムとして複数の推薦方式が存在しますが、その中で現在もっとも広く利用されているのはAES(Advanced Encryption Standard)です。AESはアメリカ商務省標準技術局(NIST)によって制定された米国政府認定の標準暗号方式で、現時代のスーパーコンピュータを用いても完全解読に数十億年かかると言われるほど強固な暗号方式です。このように複雑なアルゴリズムなので、鍵データの暗号処理には多くのCPUパワーが必要になってしまいます。このAES暗号処理を支援するために、IntelやAMDのx86系プロセッサの一部にはAES-NI(Advanced Encryption Standard New Instructions)という拡張命令が搭載されてます。x86系プロセッサに暗号処理支援機能が搭載されたのは、VIAのPadLockというものが最初です。IntelではWestmere(実質的にはSandy Bridge)以降、AMDはBulldozer以降のプロセッサにAES-NIが搭載されています。AES-NIの詳しい情報については下のリンクページを参照してください。

 インテル(R) AES New Instructions およびインテル(R) データ・プロテクション・テクノロジー
 Intel(R) Advanced Encryption Standard Instructions (AES-NI) | Intel(R) Developer Zone
 AES-NI - Wikipedia

AES-NIを内蔵したプロセッサが登場したのは2010年頃からでまだ比較的新しい機能ですが、この機能を利用すると暗号処理の速度が大きく向上するので、ソフトウェア側のAES-NI対応が積極的に進められています。OpenSSLでもバージョン1.0.0からこの機能を利用するコードが正式に追加されています。

Intel E38xxシリーズのプロセッサにもこのAES-NI機能が内蔵されており、Yocto LinuxのOpenSSLのレシピでは、デフォルトのビルド・コンフィグレーションでAES-NI対応機能が有効になっています。そこで、このOpenSSLのAES-NI対応機能の性能評価をやってみました。ターゲットとして使ったのはDE3815TYKHEです。Yocto Linuxのイメージは、前記事でビルドしたPoky + Valley Island BSP Daisy 1.6.2版のcore-image-satoを使いました。

最初に、DE3815TYKHEに搭載されているE3815プロセッサがAES-NIに対応していることを確認しました。
# cat /proc/cpuinfo | grep aes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp
lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm
sse4_1 sse4_2 movbe popcnt tsc_deadline_timer aes rdrand lahf_lm 3dnowprefetch arat epb dtherm tpr_shadow vnmi flexpriority ept vpid tsc_adjust smep erms

次にOpenSSLの暗号処理の速度計測をやってみました。下のコマンドを実行すると、AES-NIを利用しない場合のAES暗号処理の実行速度が計測されます。
# openssl speed aes-256-cbc
Doing aes-256-cbc for 3s on 16 size blocks: 3428104 aes-256-cbc's in 2.98s
Doing aes-256-cbc for 3s on 64 size blocks: 941294 aes-256-cbc's in 2.99s
Doing aes-256-cbc for 3s on 256 size blocks: 243703 aes-256-cbc's in 2.99s
Doing aes-256-cbc for 3s on 1024 size blocks: 158741 aes-256-cbc's in 2.99s
Doing aes-256-cbc for 3s on 8192 size blocks: 20013 aes-256-cbc's in 2.99s
OpenSSL 1.0.1j 15 Oct 2014
built on: Mon Dec 29 20:18:13 JST 2014
options:bn(64,64) rc4(16x,int) des(idx,cisc,16,int) aes(partial) idea(int) blowfish(idx)
compiler: x86_64-poky-linux-gcc -m64 -march=corei7 -mtune=corei7 -mfpmath=sse -msse4.2 --sysroot=/home/yuhri/Yocto/poky-daisy-11.0.2/de3815tybe/tmp/sysroots/
de3815tybe-64 -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -O2 -pipe -g -feliminate-unused-debug-types
-Wall -Wa,--noexecstack -DHAVE_CRYPTODEV -DUSE_CRYPTODEV_DIGESTS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m
-DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
aes-256 cbc 18405.93k 20148.10k 20865.54k 54364.81k 54831.60k

続いて、AES-NIを利用する場合のAES暗号処理の実行速度を計測してみました。
# openssl speed -evp aes-256-cbc
Doing aes-256-cbc for 3s on 16 size blocks: 20268390 aes-256-cbc's in 2.98s
Doing aes-256-cbc for 3s on 64 size blocks: 6844410 aes-256-cbc's in 2.99s
Doing aes-256-cbc for 3s on 256 size blocks: 2006895 aes-256-cbc's in 2.99s
Doing aes-256-cbc for 3s on 1024 size blocks: 524359 aes-256-cbc's in 2.99s
Doing aes-256-cbc for 3s on 8192 size blocks: 66350 aes-256-cbc's in 2.99s
OpenSSL 1.0.1j 15 Oct 2014
built on: Mon Dec 29 20:18:13 JST 2014
options:bn(64,64) rc4(16x,int) des(idx,cisc,16,int) aes(partial) idea(int) blowfish(idx)
compiler: x86_64-poky-linux-gcc -m64 -march=corei7 -mtune=corei7 -mfpmath=sse -msse4.2 --sysroot=/home/yuhri/Yocto/poky-daisy-11.0.2/de3815tybe/tmp/sysroots/
de3815tybe-64 -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -O2 -pipe -g -feliminate-unused-debug-types
-Wall -Wa,--noexecstack -DHAVE_CRYPTODEV -DUSE_CRYPTODEV_DIGESTS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m
-DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
aes-256 cbc 108823.57k 146502.42k 171827.80k 179579.80k 181785.69k

openssl speed」コマンドに「-evp」というオプションを付加すると、ハードウェア側の暗号処理支援機能が使われます。

上の2つの計測値を比較すると、AES-NI利用の有無によって処理速度に3〜8倍の差が出ています(数値が大きい方が高速です)。この結果から、AES-NIの性能がいかに優れているかということが判ります。

SSE(Streaming SIMD Extensions)もそうですが、x86系プロセッサではソフトウェア側の負荷が高い処理を支援する拡張機能が積極的に搭載されます。Intelのプロセッサの設計技術と製造技術が並外れて高いからですが、こういう対応はARM系よりx86系プロセッサの方が断然早いです。組込み機器でx86系プロセッサを採用するメリットはこういう点にも現れると言えるでしょう。

【参考ページ】

 AES-NIという加速装置のお話 - geniee’s tech blog
 見せてもらおうか、IntelのAES-NIの性能とやらを 〜OpenSSLでベンチしてみた〜 - ..たれろぐ..
posted by とみやん at 11:15| Comment(0) | TrackBack(0) | Embedded Linux > Yocto Project

2014年12月29日

[Yocto] Poky Daisy 1.6.2: Intel E38xx BSPのDE3815TYKHEでの動作確認

前記事に書いたとおり、Intel E38xx用のYocto Linuxビルド環境をDaisy 1.6.1からDaisy 1.6.2にバージョンアップしました。Poky(Yocto Project Core)のDaisy 1.6.2版がリリースされたのが2014/12/05で、Valley Island(Intel E38xx)BSPのDaisy 1.6.2版はそれから少し遅れて2014/12/19にリリースにされています。PokyとBSPの両方が揃ったので、年内にDaisy 1.6.2版へのバージョンアップをやってしまいたかったからです。

Valley Island BSPの配布パッケージにはビルド済みのcore-image-satoイメージのhddimgファイルが収納されているので、手っ取り早くこのファイルからLive USBを作成して、それを使ってターゲットで動作確認をやることもできます。すでにそちらは行ってみたのですが、改めてIntel E38xx用のYocto Linux Daisy 1.6.2版ビルド環境を構築して、一からcore-image-satoイメージをビルドして、この自分でクリーン・ビルドしたイメージを使ってDE3815TYKHEでYocto Linuxを動かしてみました。

Daisy 1.6.1版で同じ作業をやっており、その作業記録は09/2410/13の記事に掲載済みですが、改めてDaisy 1.6.2版でのIntel E38xx用Yocto Linuxビルド環境の構築とDE3815TYKHEでの動作確認作業の記録を残します。

まずは、Daisy 1.6.2公式リリース版のパッケージファイルのダウンロードとその展開から始めました。
% cd ~/Yocto
% wget http://downloads.yoctoproject.org/releases/yocto/yocto-1.6.2/poky-daisy-11.0.2.tar.bz2
% tar -jxvf poky-daisy-11.0.2.tar.bz2
% wget http://downloads.yoctoproject.org/releases/yocto/yocto-1.6.2/machines/valleyisland/valleyisland-1.0-daisy-1.6.2.tar.bz2
% tar -jxvf valleyisland-1.0-daisy-1.6.2.tar.bz2
% mv valleyisland-1.0-daisy-1.6.2/meta-intel poky-daisy-11.0.2
$ rmdir valleyisland-1.0-daisy-1.6.2

また、ついでにOpenEmbedded Gitリポジトリからmeta-openembeddedツリーのパッケージレシピ群を取得しておきました。
% cd poky-daisy-11.0.2
% git clone git://git.openembedded.org/meta-openembedded -b daisy

これでIntel E38xx用のビルド環境は完成ですが、DE3815TYKHEをターゲットとしてYocto Linuxをビルドするので、DE3815TYKHE用のBSPを追加しました。同BSPの作成手順は10/25の記事に書いたとおりですが、Valley Island BSP Daisy 1.6.2版はRealtek RTL8111用ドライバが有効になっているので、同ドライバをカーネルへ組み込むための変更は加えていません。一応DE3815TYKHE BSP Daisy 1.6.2版のターゲット定義ファイルとカーネルレシピの内容を以下に掲載しておきます。
#@TYPE: Machine
#@NAME: Intel DE3815TYBE (Thin Canyon) board which is embedded in NUC Kit DE3815TYKHE

#@WEBTITLE: Intel Atom E38xx Processor (DE3815TYBE) 32-bit with Open Source Frame Buffer Graphics

#@DESCRIPTION: Machine configuration for DE3815TYBE 32-bit systems, without Intel-proprietary graphics bits

PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
PREFERRED_VERSION_linux-yocto ?= "3.10%"

require conf/machine/include/intel-core2-32-common.inc
require conf/machine/include/intel-common-pkgarch.inc
require conf/machine/include/meta-intel.inc

MACHINE_FEATURES += "pcbios efi"
MACHINE_FEATURES += "wifi"

MACHINE_EXTRA_RRECOMMENDS += "linux-firmware"

XSERVER ?= "${XSERVER_X86_BASE} \
${XSERVER_X86_EXT} \
${XSERVER_X86_FBDEV} \
${XSERVER_X86_I965} \
"

APPEND += "acpi_enforce_resources=lax video=efifb:off vga=0x318"

#@TYPE: Machine
#@NAME: Intel DE3815TYBE (Thin Canyon) board which is embedded in NUC Kit DE3815TYKHE

#@WEBTITLE: Intel Atom E38xx Processor (DE3815TYBE) 64-bit with Open Source Frame Buffer Graphics

#@DESCRIPTION: Machine configuration for DE3815TYBE 64-bit systems, without Intel-proprietary graphics bits

PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
PREFERRED_VERSION_linux-yocto ?= "3.10%"

require conf/machine/include/intel-corei7-64-common.inc
require conf/machine/include/intel-common-pkgarch.inc
require conf/machine/include/meta-intel.inc

MACHINE_FEATURES += "pcbios efi"
MACHINE_FEATURES += "wifi"

MACHINE_EXTRA_RRECOMMENDS += "linux-firmware"

XSERVER ?= "${XSERVER_X86_BASE} \
${XSERVER_X86_EXT} \
${XSERVER_X86_FBDEV} \
${XSERVER_X86_I965} \
"

APPEND += "acpi_enforce_resources=lax video=efifb:off vga=0x318"

FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"

#############################
# MACHINE = de3815tybe-32 #
#############################
COMPATIBLE_MACHINE_de3815tybe-32 = "de3815tybe-32"
KMACHINE_de3815tybe-32 = "valleyisland-32"
KBRANCH_de3815tybe-32 = "standard/base"
KERNEL_FEATURES_de3815tybe-32 = " features/valleyisland-io/valleyisland-io.scc \
features/valleyisland-io/valleyisland-io-pci.scc \
features/wifi/wifi-all.scc"

LINUX_VERSION_de3815tybe-32 = "3.10.59"
SRCREV_machine_de3815tybe-32 = "747e1cbd12b15db8bc2ae86e2359c1b113f120d6"
SRCREV_meta_de3815tybe-32 = "8f05306a8e6f5ee422d50c3317acce0cf9e6aada"
SRCREV_valleyisland-io_de3815tybe-32 = "0992d01f5f382f6da60004ef87f67ebd3ca13732"

SRC_URI_de3815tybe-32 = "git://git.yoctoproject.org/linux-yocto-3.10.git;protocol=git;nocheckout=1;branch=${KBRANCH},${KMETA},valleyisland-io-3.0;name=machine,meta,valleyisland-io"

#############################
# MACHINE = de3815tybe-64 #
#############################
COMPATIBLE_MACHINE_de3815tybe-64 = "de3815tybe-64"
KMACHINE_de3815tybe-64 = "valleyisland"
KBRANCH_de3815tybe-64 = "standard/base"
KERNEL_FEATURES_de3815tybe-64 = " features/valleyisland-io/valleyisland-io.scc \
features/valleyisland-io/valleyisland-io-pci.scc \
features/wifi/wifi-all.scc"

LINUX_VERSION_de3815tybe-64 = "3.10.59"
SRCREV_machine_de3815tybe-64 = "747e1cbd12b15db8bc2ae86e2359c1b113f120d6"
SRCREV_meta_de3815tybe-64 = "8f05306a8e6f5ee422d50c3317acce0cf9e6aada"
SRCREV_valleyisland-io_de3815tybe-64 = "0992d01f5f382f6da60004ef87f67ebd3ca13732"

SRC_URI_de3815tybe-64 = "git://git.yoctoproject.org/linux-yocto-3.10.git;protocol=git;nocheckout=1;branch=${KBRANCH},${KMETA},valleyisland-io-3.0;name=machine,meta,valleyisland-io"

module_autoload_i2c-dev = "i2c-dev"

上ではWi-Fi端末機能と無線LANドライバが有効になっていますが、これはDE3815TYKHEに無線LANカードを取り付け済みだからです。ターゲットに無線LANカードが搭載されていない場合は、ハイライト表示の部分は削除しても構いません。このままビルドしたイメージを無線LANカード未搭載のターゲットで動かしても、特に問題は発生しないと思います。

DE3815TYKHE用のYocto Linuxビルド環境が整ったので、さっそくcore-image-satoイメージをビルドしてみました。まずは、oe-init-build-envスクリプトを使ってビルド作業ディレクトリを作成しました。
% cd ~/Yocto
% cd poky-daisy-11.0.2
% . ./oe-init-build-env de3815tybe

そして、oe-init-build-envスクリプトによって生成されたbblayers.conflocal.confを以下のように編集しました。
--- conf/bblayers.conf.000	2014-12-29 17:45:51.120393760 +0900
+++ conf/bblayers.conf 2014-12-29 18:04:41.401863776 +0900
@@ -9,6 +9,9 @@
/home/yuhri/Yocto/poky-daisy-11.0.2/meta \
/home/yuhri/Yocto/poky-daisy-11.0.2/meta-yocto \
/home/yuhri/Yocto/poky-daisy-11.0.2/meta-yocto-bsp \
+ /home/yuhri/Yocto/poky-daisy-11.0.2/meta-intel \
+ /home/yuhri/Yocto/poky-daisy-11.0.2/meta-intel/meta-tlk \
+ /home/yuhri/Yocto/poky-daisy-11.0.2/meta-de3815tybe \
"
BBLAYERS_NON_REMOVABLE ?= " \
/home/yuhri/Yocto/poky-daisy-11.0.2/meta \

--- conf/local.conf.000	2014-12-29 17:45:51.120393760 +0900
+++ conf/local.conf 2014-12-29 17:53:41.423015554 +0900
@@ -17,18 +17,18 @@
# These two options control how much parallelism BitBake should use. The first
# option determines how many tasks bitbake should run in parallel:
#
-#BB_NUMBER_THREADS ?= "4"
+BB_NUMBER_THREADS ?= "12"
#
# Default to setting automatically based on cpu count
-BB_NUMBER_THREADS ?= "${@oe.utils.cpu_count()}"
+#BB_NUMBER_THREADS ?= "${@oe.utils.cpu_count()}"
#
# The second option controls how many processes make should run in parallel when
# running compile tasks:
#
-#PARALLEL_MAKE ?= "-j 4"
+PARALLEL_MAKE ?= "-j 12"
#
# Default to setting automatically based on cpu count
-PARALLEL_MAKE ?= "-j ${@oe.utils.cpu_count()}"
+#PARALLEL_MAKE ?= "-j ${@oe.utils.cpu_count()}"
#
# For a quad-core machine, BB_NUMBER_THREADS = "4", PARALLEL_MAKE = "-j 4" would
# be appropriate for example.
@@ -55,7 +55,8 @@
#MACHINE ?= "edgerouter"
#
# This sets the default machine to be qemux86 if no other machine is selected:
-MACHINE ??= "qemux86"
+MACHINE ?= "de3815tybe-64"
+MACHINE ??= "valleyisland-64"

これでDE3815TYKHE用にYocto Linuxをビルドするための条件がすべて整ったので、bitbakeコマンドを使ってcore-image-satoイメージのビルドを行いました。
% bitbake core-image-sato -c fetchall
% bitbake core-image-sato

最初の全ソースのダウンロードに30分(インターネット回線はWiMAX 2+モバイルルータ)、続くcore-image-satoイメージのクリーン・ビルドに3時間35分かかりました(Intel Core i7 2.7GHz プロセッサコア数4、メモリ4GB、ストレージThuderbolt RAID 0 HDDという構成のVMware仮想マシンの場合)。

ビルドが完了するまで、食事をしたりニコニコ動画でアニメを鑑賞しながら過ごしました。core-image-satoイメージのビルドはとにかく時間がかかります。特にストレージがSSDかHDDかでビルド時間に1.5〜2倍の差が生まれます。それと、local.conf内のBB_NUMBER_THREADSとPARALLEL_MAKEの値はすごく重要です。この2つ変数の設定値によってもビルド時間に2〜5倍の差が出ます。また、Yocto Linxはやたらとディスク容量を食います。一ターゲットあたり30〜50GB位のディスク容量が必要になります。複数のターゲットのビルドをやると、すぐにディスク消費量が100GBを超えてしまいます。Yocto Linxの開発では、高性能なPCと大容量のSSDは必須だと思った方が良いです(もし会社で低性能なPCしか与えられられなかったら、毎日終電近くまで残業して休日出勤までしなければならないような地獄の日々を過ごす羽目になるでしょう。会社の仕事でYocto Linxの開発を始めるときは、大容量SSDを内蔵した高性能なPCを用意するように会社側に要求するべきです。この条件を満たさなければ仕事はしないと宣言した方が良いです。仕事に適したPCを社員に提供することは会社側の義務なんですから)。ビルド時間がかかることに関しては、退勤前や就寝前に始めるか他の事でもやりながらひたすら待つしかありません。

ビルドが終わったので(ソース・ダウンロードを始めたのが夕方6時頃で、ビルドが終わったのは夜10時頃でした。やっぱりSSD内蔵のPCを使うか、終夜稼働ビルドでもやらないとダメですね)、core-image-satoのイメージファイルが生成されていることを確認した後、Live USBメディアを作成しました。
% ls tmp/deploy/images/de3815tybe-64 
bootx64.efi
bzImage
bzImage--3.10.59+git0+8f05306a8e_747e1cbd12-r0-de3815tybe-64-20141229094113.bin
bzImage-de3815tybe-64.bin
core-image-minimal-initramfs-de3815tybe-64-20141229094113.rootfs.cpio.gz
core-image-minimal-initramfs-de3815tybe-64-20141229094113.rootfs.manifest
core-image-minimal-initramfs-de3815tybe-64.cpio.gz
core-image-minimal-initramfs-de3815tybe-64.manifest
core-image-sato-de3815tybe-64-20141229094113.hddimg
core-image-sato-de3815tybe-64-20141229094113.iso
core-image-sato-de3815tybe-64-20141229094113.rootfs.ext3
core-image-sato-de3815tybe-64-20141229094113.rootfs.manifest
core-image-sato-de3815tybe-64.ext3
core-image-sato-de3815tybe-64.hddimg
core-image-sato-de3815tybe-64.iso
core-image-sato-de3815tybe-64.manifest
modules--3.10.59+git0+8f05306a8e_747e1cbd12-r0-de3815tybe-64-20141229094113.tgz
modules-de3815tybe-64.tgz
README_-_DO_NOT_DELETE_FILES_IN_THIS_DIRECTORY.txt

% umount /dev/sdc
% sudo dd if=tmp/deploy/images/de3815tybe-64/core-image-sato-de3815tybe-64.hddimg of=/dev/sdc
% sync

DE3815TYKHEでYocto Linuxが動作している様子は10/13の記事に掲載済みで、Sato Mobile Destopの画面や機能は特に変わっていないので、本記事では省略します。

ちなみに、Valley Island BSP Daisy 1.6.2版に収納されているhddimgファイルでは確認済みでしたが、今回クリーン・ビルドした core-image-satoイメージでも、DE3815TYKHEでeth0インターフェースはちゃんと生成されていました。やはり同版では、カーネルへr8169ドライバが組み込まれているようです。

【2014/12/30 追記】

Valley Island BSP Daisy 1.6.2版の大きな変更点は次の3つのようです(括弧内はDaisy 1.6.1版)。
  1. Gitリポジトリのカーネルソース・ブランチがvalleyisland-io-3.0へ変更された。(valleyisland-io-2.0)
  2. カーネルのバージョンが3.10.59へ更新された。(3.10.43)
  3. リファレンスターゲットとして、MinnowBoard MAXが追加された。

3の変更は大きいと思いますが、MinnowBoard MAXの入手性が悪すぎるのであまり嬉しくないですね。ググっても、MinnowBoard MAXの動作確認情報のヒット数は少ないです。上のMinnowBoard MAXのページに販売代理店のリンクが載っていますが、いずれも在庫0で入庫予定期間も2ヶ月以上になっています。メーカーのCircuitCoに本ボードの製造数を増やせない事情が何かあるのでしょう。もしかすると、IntelからのE3815やE3825 CPUの供給量がかなり少ないのかもしれません。ググってみても、E38xx搭載ボードの種類や情報が全体的に少ないからです。多くのタブレットで採用されているZ37xxの製造の方をIntelが優先しているんじゃないかと想像しています。すごく欲しいボードなのですが、私はもうMinnowBoard MAXの入手は諦めています。

どこかのメーカーがE38xx搭載ボードを私へ提供してくれると嬉しいのですが。国内の販売代理店でも構いません。無償または安価にボードを提供してくれたら、顧客向けにLinux移植のサポートとコンサルティングをやりますよ(つまり、FAEとして営業や技術活動に協力します)。本記事を読んでいるメーカーの中の人がいたら、ぜひ会社の担当者へ伝えください。
posted by とみやん at 18:37| Comment(0) | TrackBack(0) | Embedded Linux > Yocto Project

2014年12月28日

[Yocto] Poky Daisy 1.6.1: lttng-modulesコンパイルエラーの解決方法

Yocto Projectの公式サイトで、Poky(Yocto Project Core)とValley Island(Intel E38xx)BSPの両方のDaisy 1.6.2版がリリースされたので、Yocto Linuxのビルド環境をこの組み合わせにバージョンアップしました。いままで私が使っていたのはいずれものDaisy 1.6.1版でした。なお、どちらも最新版はDizzy 1.7ですが、当面の間はDaisy 1.6.2をメインに使っていきます。そのうちDizzy 1.7の方も試すつもりですが、こちらはサブのビルド環境になるでしょう。

Daisy 1.6.2にバージョンアップしてしまったので、いまさらになりますが、Poky + Valley Island BSP Daisy 1.6.1のYocto Linux環境に関する一つのTips情報があるので、記事として残しておきます。この組み合わせで、lttng-modulesというパッケージをビルドしようとすると、以下のようなコンパイルエラーが発生します。
% bitbake lttng-modules
.... ....
.... ....
ERROR: Logfile of failure stored in: /home/yuhri/Yocto/poky-daisy-11.0.1/valleyisland/tmp/work/valleyisland_64-poky-linux/lttng-modules/2.4.0-r0/temp/log.do_compile.3530
Log data follows:
| DEBUG: Executing shell function do_compile
| NOTE: make -j 12 -e MAKEFLAGS= KERNEL_PATH=/home/yuhri/Yocto/poky-daisy-11.0.1/valleyisland/tmp/sysroots/valleyisland-64/usr/src/kernel KERNEL_SRC=/home/yuhri/Yocto/poky-daisy-11.0.1/valleyisland/tmp/sysroots/valleyisland-64/usr/src/kernel KERNEL_VERSION=3.10.43-ltsi-yocto-standard CC=x86_64-poky-linux-gcc LD=x86_64-poky-linux-ld.bfd AR=x86_64-poky-linux-ar
| make -C /home/yuhri/Yocto/poky-daisy-11.0.1/valleyisland/tmp/sysroots/valleyisland-64/usr/src/kernel M=/home/yuhri/Yocto/poky-daisy-11.0.1/valleyisland/tmp/work/valleyisland_64-poky-linux/lttng-modules/2.4.0-r0/git modules
| make[1]: Entering directory `/home/yuhri/Yocto/poky-daisy-11.0.1/valleyisland/tmp/sysroots/valleyisland-64/usr/src/kernel'
| CC [M] /home/yuhri/Yocto/poky-daisy-11.0.1/valleyisland/tmp/work/valleyisland_64-poky-linux/lttng-modules/2.4.0-r0/git/lttng-ring-buffer-client-discard.o
| CC [M] /home/yuhri/Yocto/poky-daisy-11.0.1/valleyisland/tmp/work/valleyisland_64-poky-linux/lttng-modules/2.4.0-r0/git/lttng-ring-buffer-client-overwrite.o
| CC [M] /home/yuhri/Yocto/poky-daisy-11.0.1/valleyisland/tmp/work/valleyisland_64-poky-linux/lttng-modules/2.4.0-r0/git/lttng-ring-buffer-metadata-client.o
| CC [M] /home/yuhri/Yocto/poky-daisy-11.0.1/valleyisland/tmp/work/valleyisland_64-poky-linux/lttng-modules/2.4.0-r0/git/lttng-ring-buffer-client-mmap-discard.o
.... ....
.... ....
.... ....
.... ....
.... ....
.... ....
| CC [M] /home/yuhri/Yocto/poky-daisy-11.0.1/valleyisland/tmp/work/valleyisland_64-poky-linux/lttng-modules/2.4.0-r0/git/probes/lttng-probe-signal.o
| CC [M] /home/yuhri/Yocto/poky-daisy-11.0.1/valleyisland/tmp/work/valleyisland_64-poky-linux/lttng-modules/2.4.0-r0/git/probes/lttng-probe-block.o
| In file included from /home/yuhri/Yocto/poky-daisy-11.0.1/valleyisland/tmp/work/valleyisland_64-poky-linux/lttng-modules/2.4.0-r0/git/probes/../instrumentation/events/lttng-module/../../../probes/define_trace.h:148:0,
| from /home/yuhri/Yocto/poky-daisy-11.0.1/valleyisland/tmp/work/valleyisland_64-poky-linux/lttng-modules/2.4.0-r0/git/probes/../instrumentation/events/lttng-module/block.h:932,
| from /home/yuhri/Yocto/poky-daisy-11.0.1/valleyisland/tmp/work/valleyisland_64-poky-linux/lttng-modules/2.4.0-r0/git/probes/lttng-probe-block.c:41:
| /home/yuhri/Yocto/poky-daisy-11.0.1/valleyisland/tmp/work/valleyisland_64-poky-linux/lttng-modules/2.4.0-r0/git/probes/../instrumentation/events/lttng-module/../../../probes/lttng-events.h:151:6: error: conflicting types for 'trace_block_rq_complete'
| void trace_##_name(_proto);
| ^
| /home/yuhri/Yocto/poky-daisy-11.0.1/valleyisland/tmp/work/valleyisland_64-poky-linux/lttng-modules/2.4.0-r0/git/probes/../instrumentation/events/lttng-module/../../../probes/lttng-events.h:117:2: note: in expansion of macro 'DEFINE_EVENT_MAP'
| DEFINE_EVENT_MAP(template, name, name, PARAMS(proto), PARAMS(args))
| ^
| /home/yuhri/Yocto/poky-daisy-11.0.1/valleyisland/tmp/work/valleyisland_64-poky-linux/lttng-modules/2.4.0-r0/git/probes/../instrumentation/events/lttng-module/../../../probes/../instrumentation/events/lttng-module/block.h:235:1: note: in expansion of macro 'DEFINE_EVENT'
| DEFINE_EVENT(block_rq_with_error, block_rq_complete,
| ^
| In file included from include/linux/module.h:18:0,
| from /home/yuhri/Yocto/poky-daisy-11.0.1/valleyisland/tmp/work/valleyisland_64-poky-linux/lttng-modules/2.4.0-r0/git/probes/lttng-probe-block.c:23:
| include/linux/tracepoint.h:168:21: note: previous definition of 'trace_block_rq_complete' was here
| static inline void trace_##name(proto) \
| ^
| include/linux/tracepoint.h:265:3: note: in expansion of macro '__DECLARE_TRACE'
| __DECLARE_TRACE(name, PARAMS(proto), PARAMS(args), 1, \
| ^
| include/linux/tracepoint.h:395:2: note: in expansion of macro 'DECLARE_TRACE'
| DECLARE_TRACE(name, PARAMS(proto), PARAMS(args))
| ^
| include/trace/events/block.h:143:1: note: in expansion of macro 'TRACE_EVENT'
| TRACE_EVENT(block_rq_complete,
| ^
| make[3]: *** [/home/yuhri/Yocto/poky-daisy-11.0.1/valleyisland/tmp/work/valleyisland_64-poky-linux/lttng-modules/2.4.0-r0/git/probes/lttng-probe-block.o] Error 1
| make[2]: *** [/home/yuhri/Yocto/poky-daisy-11.0.1/valleyisland/tmp/work/valleyisland_64-poky-linux/lttng-modules/2.4.0-r0/git/probes] Error 2
| make[1]: *** [_module_/home/yuhri/Yocto/poky-daisy-11.0.1/valleyisland/tmp/work/valleyisland_64-poky-linux/lttng-modules/2.4.0-r0/git] Error 2
| make[1]: Leaving directory `/home/yuhri/Yocto/poky-daisy-11.0.1/valleyisland/tmp/sysroots/valleyisland-64/usr/src/kernel'
| make: *** [default] Error 2
| ERROR: oe_runmake failed
| WARNING: exit code 1 from a shell command.
| ERROR: Function failed: do_compile (log file is located at /home/yuhri/Yocto/poky-daisy-11.0.1/valleyisland/tmp/work/valleyisland_64-poky-linux/lttng-modules/2.4.0-r0/temp/log.do_compile.3530)
ERROR: Task 7 (/home/yuhri/Yocto/poky-daisy-11.0.1/meta/recipes-kernel/lttng/lttng-modules_2.4.0.bb, do_compile) failed with exit code '1'
NOTE: Tasks Summary: Attempted 419 tasks of which 412 didn't need to be rerun and 1 failed.
No currently running tasks (419 of 425)

Summary: 1 task failed:
/home/yuhri/Yocto/poky-daisy-11.0.1/meta/recipes-kernel/lttng/lttng-modules_2.4.0.bb, do_compile
Summary: There was 1 ERROR message shown, returning a non-zero exit code.

上のエラーログ出力の中のいくつかのキーワードを組みわあせて検索すると、Yocto Project Gitリポジトリの下のコミット情報ページがヒットします。

 https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=2934b25a37b6d1d09b6c6853959530be414931cb

ASShot-141228_0004-YoctoProject_Git-poky-2934b25a37b6d1d09b6c6853959530be414931cb-1002x1219
このコミットのコメントに記されているエラーメッセージは、上記のエラーログの一部と一致しています。

上記のコミットの更新内容を使えば、このlttng-modulesのコンパイルエラーを解決できるんじゃないかと考えて、それを実行してみました。具体的には、以下のような操作によって、既存のmeta/recipes-kernel/lttngディレクトリを上記のコミットの圧縮ファイルに収納されているlttngディレクトリと入れ替えました。
% cd ~/Downloads
% wget https://git.yoctoproject.org/cgit/cgit.cgi/poky/snapshot/poky-2934b25a37b6d1d09b6c6853959530be414931cb.tar.bz2
% tar -jxvf poky-2934b25a37b6d1d09b6c6853959530be414931cb.tar.bz2
% cd poky-2934b25a37b6d1d09b6c6853959530be414931cb
% mkdir ~/Yocto/poky-daisy-11.0.1/_orig_
% mv ~/Yocto/poky-daisy-11.0.1/meta/recipes-kernel/lttng ~/Yocto/poky-daisy-11.0.1/_orig_
% cp -rp meta/recipes-kernel/lttng ~/Yocto/poky-daisy-11.0.1/meta/recipes-kernel

上の操作を行った後、再度lttng-modulesのビルドを試みると、見事にビルドに成功しました。ちなみに、meta/recipes-kernel/lttng/を上記のコミットの更新内容と入れ替えると、lttng-modulesのバージョンは2.4.0から2.4.1に変わります。

どうやら、このlttng-modules_2.4.0のコンパイルエラーは特定のバージョンのカーネルとの組み合わせで起きるエラーのようです。上記のコミットのコメントには "The 3.15, and 3.14.5+ kernels introduced a change to trace_block_rq_complete, which triggers the following build error: " と記されていますが、Valley Island BSP Daisy 1.6.1のデフォルトのカーネル・バージョンは3.10.43です。多分このlttng-modules_2.4.0のコンパイルエラーは3.10.xでも起きるものなのでしょう。なお、QEMU x86 BSPとの組わあせでlttng-modules_2.4.0をビルドしたときは、このコンパイルエラーは起きません。Poky Daisy 1.6.1に収納されているQEMU x86 BSPのデフォルトのカーネル・バージョンは3.14.0です。

また、Yocto Linuxの*-sdkイメージ(core-image-sato-sdkなど)をビルドすると、その処理の過程でlttng-modulesもビルドされます。そのため、lttng-modulesの本コンパイルエラーに遭遇します(core-image-sato-sdkのビルドは高性能なPCでも3時間以上かかりますが、lttng-modulesのコンパイルエラーはその後半以降の終わりに近い所で起きます)。

いずれにしても、Valley Island以外のBSPでもカーネルのバージョンによって本コンパイルエラーに遭遇する可能性があるので、Poky Daisy 1.6.1のlttngは上記のコミットの更新内容と入れ替えておくことをお勧めします。
posted by とみやん at 15:03| Comment(0) | TrackBack(0) | Embedded Linux > Yocto Project

2014年12月14日

[Yocto] DE3815TYKHEのWi-Fiアクセスポイント化

9月からYocto Linuxの記事ばかり立て続けに投稿してきましたが(と言っても、月1〜2本のペースでしたが)、組込みLinuxに特化しすぎていて、記事の内容がちょっと偏りすぎているとなぁと思いながら書いてきました。組込みLinuxを仕事にしているエンジニアか同分野に深い興味を持っている人にしか役に立たない記事ばかりだったかもしれません。本業でやっているYocto Linux関連の仕事があまりに忙しすぎて、これ以外の研究テーマに時間を避けなくなっていることが悩みでした。この仕事のおかげで組込みLinuxのスペシャリストには成れましたが、組込み分野の最新トレンドとはかけ離れすぎていることは自覚しています。アクセス解析の情報でも、Yocto Linuxの記事のアクセス数や訪問者数は少ないです。こういう専門性の高い記事を検索する人はやはり少ないのでしょうね。Arduino, mbed, Raspberry Piなどのボードを使って、お手軽に電子工作をやったり、スマホ連携アプリを作ったりするのがいまの流行りであることは知っています。ググれば、こういうページがたくさんヒットしますし、書店で見かける専門誌でもこういう内容を特集しているものが増えています。ブログサイトの訪問者の大多数は検索エンジン経由なので、記事の中に流行りのボードの名前が含まれていれば、一気にアクセス数が伸びたりするんだと思います。組込み系の記事を書くにしてももう少しライトな内容にすべきかなぁと思って、いま色々なネタを仕込み中です。本業の仕事もやっと一段落してきたので、来年から記事の傾向を少し変えていくつもりです。

さて、前記事では、Yocto LinuxにWi-Fi端末機能を追加する方法について解説しました。無線LANカードを組み込んだDE3815TYKHEをターゲット機として使いましたが、こういう機器をWi-Fi(無線LAN)アクセスポイントとして使いたいという需要もあるんじゃないかと思います。組込みLinuxでWi-Fiアクセスポイントを構築する場合、hostapdというソフトウェアを使います。Yocto Linuxにもhostapdのパッケージレシピが存在しているので、このレシピを利用すれば、結構簡単にWi-Fiアクセスポイントを構築することができます。ただし、前記事のWi-Fi端末システムよりはずっと難易度は高くなります。Yocto Linuxのパッケージレシピやイメージレシピをカスタマイズしなければならないからです。これらの解説も兼ねて、Yocto LinuxでWi-Fiアクセスポイント・システムを構築する方法について紹介しましょう。

先にWi-Fiアクセスポイント・システムの要となるhostapdに関する情報ですが、hostapdのレシピはYocto ProjectのGitリポジトリではなく、下のOpenEmbeddedのGitリポジトリの方で管理されています。

 OpenEmbedded Git Repository Browser
 OpenEmbedded Metadata Index - layers

OpenEmbeddedというのは、Yocto Projectの源流になった組込みLinuxディストリビューションです。OpenEmbeddedはシャープのZaurus SLシリーズ(俗称「リナザウルス」)向けLinuxのビルド・フレームワークとして出発したオープンソースプロジェクトでした。発足時のターゲットはZaurusだけがでしたが、その後ARMプロセッサ搭載ハードウェアを中心として多様なターゲットに移植されて、Angstrom DistributionFamiliar LinuxなどOpenEmbeddedから派生した組込みLinuxディストリビューションが生まれています。Yocto ProjectのbitbakeコマンドやレシピなどはOpenEmbeddedによって生み出された資産を継承したものです。Yocto Linux関連のディープな技術情報を調べたい場合は、「OpenEmbedded」というキーワードを付加して検索すると、目的に適ったページが見つかることが多いです。

上のOpenEmbedded Gitリポジトリには、Yocto Projectの配布パッケージに収納されているものと同じ内容のパッケージレシピ群も存在します。同リポジトリの「openembedded-core」というツリーがそれです。Yocto Projectの公式サイトで配布されているPoky(Yocto Project Core)パッケージには、このopenembedded-coreツリーのパッケージレシピだけが格納されています。Yocto Linuxのレシピを眺めていて、「何だか、パッケージの数が少ないなぁ」と思った方がいるんじゃないでしょうか。それは、組込みLinuxでの利用頻度の高い主要なパッケージだけがopenembedded-coreツリーに収集されているからです。マイナーな分野向けパッケージは「meta-openembedded」ツリーの方に収集されています。

OpenEmbeddedのmeta-openembeddedリポジトリのパッケージレシピ群は、以下のコマンドによって取得することができます。
$ cd ~/Yocto
$ cd poky-daisy-11.0.1
$ git clone git://git.openembedded.org/meta-openembedded -b daisy

-b」オプションでブランチを指定しているので、上のコマンドによって取得できるのは、Yocto Linuxの前リリースDaisyのパッケージレシピ群です。最新リリースDizzyのパッケージレシピ群を取得したい場合は、このオプションを「-b dizzy」に変えてください。meta-openembeddedリポジトリの格納先ディレリトは何処に作成してもでも構いませんが、私の場合は、ブランチと一致するPoky格納先ディレクトリの直下に作成しています。上のコマンドを実行すると、poky-daisy-11.0.1ディレクトリの中にmeta-openembeddedというディレクトリが作成されます。ちなみに、Yocto Linuxの全レシピをGitリポジトリから取得してPokyを構成したい場合は、以下のコマンドによってそれができます。
$ cd ~/Yocto
$ git clone git://git.yoctoproject.org/poky.git -b daisy poky-daisy
$ cd poky-daisy
$ git clone git://git.yoctoproject.org/meta-intel.git -b daisy
$ git clone git://git.openembedded.org/meta-openembedded -b daisy

上では、BSPはYocto Project Gitリポジトリの「meta-intel」ツリーから取得していますが、このリポジトリ・ツリーにはIntel x86系プロセッサ搭載ターゲット用のすべての種類のBSPレシピが管理されています。meta-intelリポジトリ・ツリーからBSPレシピを取得すれば、x86系プロセッサを搭載したほとんどの種類のターゲットへYocto Linuxを移植することができます。なお、x86系プロセッサ以外のBSPは他のリポジトリ・ツリーで管理されているので、それらを取得したい場合は、Yocto Project Gitリポジトリから探してください。Yocto ProjectやOpenEmbeddedで管理されているもの以外にもBSPは存在しています。OpenEmbeddedから派生したプロジェクトのアーカイブページやGitリポジトリにもBSPが収集されているので、これらのサイトを探すと見つかったりします。

上で紹介したmeta-openembeddedリポジトリには非常に多く種類のパッケージレシピが収集されており、組込みLinuxで利用されるソフトウェアのほとんどがこの中に存在しています。Yocto Linuxの配布パッケージに収納されているopenembedded-coreリポジトリのパッケージレシピ群だけではマイナーな用途向けのシステムを構築するのは難しいでしょう。その場合は、上記のmeta-openembeddedリポジトリから取得したパッケージレシピ群を追加すると、目的に合ったシステムを構築できることが多いです。この2つは常に一緒に利用することをお勧めします。

■ DE3815TYKHE BSPへのWi-Fi AP用ターゲットの追加


meta-openembeddedリポジトリからパッケージレシピを取得したら、その中に含まれているhostapdのレシピを使って、Yocto Linuxへhostapdを組み込むことができます。Wi-Fi AP用システムに追加すべきWi-Fi関連パッケージは次の5つです。
  • linux-firmware-*
  • connman
  • wireless-tools
  • hostapd-daemon
  • busybox-udhcpd

これらのパッケージをシステム構成イメージへ組み込めば、Wi-Fi AP用のシステムを構築できます。

DE3815TYKHEをWi-Fi APとして使用するにあたって、同BSPへWi-Fi AP用の新しいターゲット定義を追加することにしました。組込みLinuxではWi-Fi端末のようなクライアント側の機器がターゲットとなるこが多いので、既存のターゲット定義を汎用として残したかったからです。Wi-Fi APのシステム構成は特殊なので、専用のターゲット定義を追加した方が良いと判断しました。Wi-Fi AP専用ターゲットの名前は、安直ですが「de3815tybe-ap」にしました。この「de3815tybe-ap」のターゲット定義ファイルの内容とカーネルレシピの変更内容を以下に示します。
#@TYPE: Machine
#@NAME: Intel DE3815TYBE (Thin Canyon) board which is embedded in NUC Kit DE3815TYKHE

#@WEBTITLE: Intel Atom E38xx Processor (DE3815TYBE) 64-bit with Open Source Frame Buffer Graphics

#@DESCRIPTION: Machine configuration for DE3815TYBE 64-bit systems, without Intel-proprietary graphics bits

PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
PREFERRED_VERSION_linux-yocto ?= "3.10%"

require conf/machine/include/intel-corei7-64-common.inc
require conf/machine/include/intel-common-pkgarch.inc
require conf/machine/include/meta-intel.inc

MACHINE_FEATURES += "pcbios efi"
MACHINE_FEATURES += "wifi"

MACHINE_EXTRA_RRECOMMENDS += "linux-firmware"

XSERVER ?= "${XSERVER_X86_BASE} \
${XSERVER_X86_EXT} \
${XSERVER_X86_FBDEV} \
${XSERVER_X86_I965} \
"

APPEND += "acpi_enforce_resources=lax video=efifb:off vga=0x318"

FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"

#############################
# MACHINE = de3815tybe-32 #
#############################
COMPATIBLE_MACHINE_de3815tybe-32 = "de3815tybe-32"
KMACHINE_de3815tybe-32 = "valleyisland-32"
KBRANCH_de3815tybe-32 = "standard/base"
KERNEL_FEATURES_de3815tybe-32 = " features/valleyisland-io/valleyisland-io \
features/valleyisland-io/valleyisland-io-pci.scc \
features/wifi/wifi-all.scc"

LINUX_VERSION_de3815tybe-32 = "3.10.43"
SRCREV_machine_de3815tybe-32 = "aa677a2d02677ec92d59a8c36d001cf2f5cf3260"
SRCREV_meta_de3815tybe-32 = "199943142f7e0a283240246ee6c02f4376b315f0"
SRCREV_valleyisland-io_de3815tybe-32 = "27bc40c174bb4ca160eafd6ccf3da9e774c9a8c7"

SRC_URI_de3815tybe-32 = "git://git.yoctoproject.org/linux-yocto-3.10.git;protocol=git;nocheckout=1;branch=${KBRANCH},${KMETA},valleyisland-io-2.0;name=machine,meta,valleyisland-io"

SRC_URI_de3815tybe-32 += "file://add_driver-net_ethernet_r8169.cfg"

#############################
# MACHINE = de3815tybe-64 #
#############################
COMPATIBLE_MACHINE_de3815tybe-64 = "de3815tybe-64"
KMACHINE_de3815tybe-64 = "valleyisland"
KBRANCH_de3815tybe-64 = "standard/base"
KERNEL_FEATURES_de3815tybe-64 = " features/valleyisland-io/valleyisland-io \
features/valleyisland-io/valleyisland-io-pci.scc \
features/wifi/wifi-all.scc"

LINUX_VERSION_de3815tybe-64 = "3.10.43"
SRCREV_machine_de3815tybe-64 = "aa677a2d02677ec92d59a8c36d001cf2f5cf3260"
SRCREV_meta_de3815tybe-64 = "199943142f7e0a283240246ee6c02f4376b315f0"
SRCREV_valleyisland-io_de3815tybe-64 = "27bc40c174bb4ca160eafd6ccf3da9e774c9a8c7"

SRC_URI_de3815tybe-64 = "git://git.yoctoproject.org/linux-yocto-3.10.git;protocol=git;nocheckout=1;branch=${KBRANCH},${KMETA},valleyisland-io-2.0;name=machine,meta,valleyisland-io"

SRC_URI_de3815tybe-64 += "file://add_driver-net_ethernet_r8169.cfg"

#############################
# MACHINE = de3815tybe-ap #
#############################
COMPATIBLE_MACHINE_de3815tybe-ap = "de3815tybe-ap"
KMACHINE_de3815tybe-ap = "valleyisland"
KBRANCH_de3815tybe-ap = "standard/base"
KERNEL_FEATURES_de3815tybe-ap = " features/valleyisland-io/valleyisland-io \
features/valleyisland-io/valleyisland-io-pci.scc \
features/wifi/wifi-all.scc \
features/hostapd/hostapd.scc"

LINUX_VERSION_de3815tybe-ap = "3.10.43"
SRCREV_machine_de3815tybe-ap = "aa677a2d02677ec92d59a8c36d001cf2f5cf3260"
SRCREV_meta_de3815tybe-ap = "199943142f7e0a283240246ee6c02f4376b315f0"
SRCREV_valleyisland-io_de3815tybe-ap = "27bc40c174bb4ca160eafd6ccf3da9e774c9a8c7"

SRC_URI_de3815tybe-ap = "git://git.yoctoproject.org/linux-yocto-3.10.git;protocol=git;nocheckout=1;branch=${KBRANCH},${KMETA},valleyisland-io-2.0;name=machine,meta,valleyisland-io"

SRC_URI_de3815tybe-ap += "file://add_driver-net_ethernet_r8169.cfg"

module_autoload_i2c-dev = "i2c-dev"

de3815tybe-ap.confconf/machine/de3815tybe-64.confをコピーしただけです。linux-yocto_3.10.bbappendの方は、同ファイル内の「de3815tybe-64」の部分をコピペして、変数名とターゲット名を変更し、さらにWi-Fi AP固有の設定を追加しています。「KERNEL_FEATURES_de3815tybe-ap = " ... features/hostapd/hostapd.scc"」という箇所がそれです。このfeatures/hostapd/hostapd.sccというファイルには、カーネルのソースツリーに存在するWi-Fi AP固有の機能を有効にするコンフィグレーション設定が含まれています。これは無線LANドライバと連携して動作するので、前記事で追加したfeatures/wifi/wifi-all.sccは残してあります。Wi-Fi AP用ターゲット「de3815tybe-ap」を追加した後のDE3815TYKHE BSPのファイル構成を以下に示します。

  meta-de3815tybe
|
|-- conf
| |-- machine
| | |-- de3815tybe-32.conf
| | |-- de3815tybe-64.conf
| | `-- de3815tybe-ap.conf
| `-- layer.conf
|-- recipes-bsp
| `-- formfactor
| |-- formfactor
| | |-- de3815tybe-32
| | | `-- machconfig
| | |-- de3815tybe-64
| | | `-- machconfig
| | `-- de3815tybe-ap
| | `-- machconfig
| `-- formfactor_0.0.bbappend
`-- recipes-kernel
`-- linux
|-- linux-yocto
| `-- add_driver-net_ethernet_r8169.cfg
`-- linux-yocto_3.10.bbappend


■ カスタム・レイヤの作成


DE3815TYKHE BSPへのWi-Fi AP用ターゲットの追加が終わったので、これ以降Yocto LinuxでWi-Fi AP用システムを構築していきます。BSPだけでなく、イメージレシピ、パッケージレシピなども改造していかないと、Yocto LinuxでWi-Fi APのような特定用途向けのシステムを構築することはできません。

10/25の記事に、新しいターゲット用のBSPを作成する場合独立したBSPレイヤに収納するのがセオリーだと書きましたが、これと同様に、特定用途向けシステム用に新しいレシピを作成したり既存のレシピを改造していく場合、これらのレシピは独立したレイヤに収納していくのがYocto Linuxのセオリーです。このセオリーに従って、ここで、先にWi-Fi APシステム用のレイヤを作成することにします。Yocto Linuxで新しいレイヤを作成するには、yocto-layerというスクリプトを使います(既存のレイヤをコピーして作成することもできますが、新しいレイヤを作成する場合は、できるだけこのyocto-layerスクリプトを使うことをお勧めします)。具体的には、以下のようなコマンドを実行すると、新しいレイヤを作成することができます。
$ cd ~/Yocto
$ cd poky-daisy-11.0.1
$ . ./oe-init-build-env de3815tybe
$ cd ..
$ yocto-layer create kronus9
Please enter the layer priority you'd like to use for the layer: [default: 6]
Would you like to have an example recipe created? (y/n) [default: n] y
Please enter the name you'd like to use for your example recipe: [default: example]
Would you like to have an example bbappend file created? (y/n) [default: n]

New layer created in meta-kronus9.

Don't forget to add it to your BBLAYERS (for details see meta-kronus9\README).

yocto-layerスクリプトは、oe-init-build-envスクリプトによって設定される環境変数を参照するので、先に一度oe-init-build-envを実行しておく必要があります。上では、既存のビルド作業ディレクトリであるde3815tybeを同スクリプトのパラメータとして指定していますが、ビルド作業ディレクトリを一つも作成していない場合は、パラメータなしでoe-init-build-envスクリプトを実行すると良いでしょう(その場合、デフォルトのbuildというビルド作業ディレクトリが作成されます)。上のコマンドを実行すると、「meta-kronus9」という名前のディレクトリが作成されます。作成直後のレイヤ・ディレクトリには以下のようなファイルが格納されています。

  meta-kronus9
|
|-- conf
| `-- layer.conf
|-- recipes-example
| `-- example
| |-- example-0.1
| | |-- example-patch
| | `-- helloworld.c
| `-- example_0.1.bb
|-- COPYING.MIT
`-- README

上のいずれのファイルも特に編集する必要はありませんが、各ファイルの内容は一度見ておくことをお勧めします。recipes-exampleディレクトリは「yocto-layers create」コマンドを実行した際の2番目の質問に「y」と入力したときに作成されます。このディレクトリには、サンプル・プログラムの定番であるhello worldアプリのソースやレシピファイルなどが格納されています。これらが必要がなれば、同質問に「n」と入力すると良いでしょう。

また、「yocto-layers create」コマンドで作成されるファイル群の中で一つ重要な役割を持っているファイルがあるので、これについて説明しておきます。レイヤ定義ファイルであるconf/layer.confがそれですが、このファイルは以下のような内容になっています。
# We have a conf and classes directory, add to BBPATH
BBPATH .= ":${LAYERDIR}"

# We have recipes-* directories, add to BBFILES
BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
${LAYERDIR}/recipes-*/*/*.bbappend"

BBFILE_COLLECTIONS += "kronus9"
BBFILE_PATTERN_kronus9 = "^${LAYERDIR}/"
BBFILE_PRIORITY_kronus9 = "6"

上の「BBFILE_PRIORITY_kronus9 」という変数の設定値は「yocto-layers create」コマンドを実行した際の1番目の質問に入力した値が適用されます。この設定値はbitbakeコマンドによってレシピファイルが参照される際の優先順位に影響を与えます。例えば、複数のレイヤに同名のレシピが存在するケースを想像してください。このようなケースにおいて、bitbakeコマンドにレシピ名だけを指定した場合、BBFILE_PRIORITYの値が大きい方のレイヤに格納されているレシピファイルの方が参照されます。レイヤを管理しているのはbblayers.confですが、このファイル内で定義している各レイヤの優先度を知りたい場合は、下のコマンドで確認することができます。
$ bitbake-layers show-layers
layer path priority
==========================================================================
meta /home/yuhri/Yocto/poky-daisy-11.0.1/meta 5
meta-yocto /home/yuhri/Yocto/poky-daisy-11.0.1/meta-yocto 5
meta-yocto-bsp /home/yuhri/Yocto/poky-daisy-11.0.1/meta-yocto-bsp 5
meta-oe /home/yuhri/Yocto/poky-daisy-11.0.1/meta-openembedded/meta-oe 6
meta-intel /home/yuhri/Yocto/poky-daisy-11.0.1/meta-intel 5
meta-de3815tybe /home/yuhri/Yocto/poky-daisy-11.0.1/meta-de3815tybe 6
meta-kronus9 /home/yuhri/Yocto/poky-daisy-11.0.1/meta-kronus9 6

以上、カスタム・レイヤの作成方法について説明しましたが、いかがでしたでしょうか。特に難しい箇所はなかったと思うので、練習のつもりで一度新しいレイヤを作成してみることをお勧めします。作成直後のレイヤ・ディレクトリにはhello worldアプリのレシピしか格納されていないので、既存のレイヤのレシピに影響を与えることはありません。

これ以降、上で作成したmeta-kronus9レイヤにWi-Fi APシステム用のレシピを追加していきますが、説明の都合上、先に最終的なファイル構成を示しておきます。

  meta-kronus9
|
|-- conf
| `-- layer.conf
|-- recipes-core
| |-- busybox
| | |-- busybox
| | | `-- de3815tybe-ap
| | | `-- udhcpd.conf
| | `-- busybox_1.22.1.bbappend
| |-- images
| | `-- kronus9-image-wifiap.bb
| `-- init-ifupdown
| |-- init-ifupdown
| | `-- de3815tybe-ap
| | `-- interfaces
| `-- init-ifupdown_1.0.bbappend
|-- recipes-connectivity
| |-- connman
| | |-- connman
| | | `-- de3815tybe-ap
| | | `-- main.conf
| | `-- connman_1.22.bbappend
| `-- hostapd
| |-- hostap-daemon
| | `-- hostapd.conf-kronus9
| `-- hostap-daemon_1.0.bbappend
|-- COPYING.MIT
`-- README


■ Wi-Fi AP用イメージレシピの作成


前記事で紹介したlocal.confに「IMAGE_INSTALL_append_pn-<IMAGE_NAME>」という設定を追加する方法によって、既存のイメージへパッケージを組み込むことができます。数個のパッケージを追加するだけなら、この方法は手っ取り早い方法なのですが、パッケージを列記しているだけなので、パッケージの種類と数が増えてくると管理が大変になってくるでしょう。

特定用途向けにシステムを構築するなら、やはりその目的に合ったイメージレシピをちゃんと作成しておくべきです。今回の目的はDE3815TYKHEをWi-Fiアクセスポイントとして使用することなので、meta-kronus9レイヤの中に以下のようなWi-Fi AP用のイメージレシピを作成しました。
#
# Copyright (C) 2014 Kronus Nine Computer Works
#

DESCRIPTION = "A console-only image for a Wi-Fi access point target."

IMAGE_FEATURES += "splash ssh-server-openssh package-management"

IMAGE_INSTALL = "\
${CORE_IMAGE_BASE_INSTALL} \
packagegroup-core-full-cmdline \
${CORE_IMAGE_EXTRA_INSTALL} \
"

inherit core-image

IMAGE_INSTALL += "\
kernel-modules \
connman \
wireless-tools \
hostap-daemon \
busybox-udhcpd \
"

「core-image」クラスレシピ(「クラスレシピ」については別の記事で解説するつもりです)を継承しているので、このイメージレシピの格納先はrecipes-core/imagesディレクトリにしました。ディレクトリ階層さえ合っていれば、レシピファイルの格納先は特に制限はありません。ただし、第2階層(レイヤ・ディレクトリの直下)のディレクトリ名は「recipes-*」でなければなりません。また、上のkronus9-image-wifiap.bbに「IMAGE_INSTALL = "... packagegroup-core-full-cmdline"」という記述が存在していることから判るかと思いますが、このイメージレシピはCLI環境用です。Wi-Fi APにGUI環境は必要ないので、GUI関連のパッケージは除外してあります。

■ hostap-daemonレシピのカスタマイズ


Wi-Fi AP用のイメージレシピを作成できたので、続いて、個々のパッケージレシピをカスタマイズしていきます。

最初に、Wi-Fi APの要となるhostapdのレシピを改造します。hostapdからいくつかのパッケージが生成されますが、改造するのはhostapdのデーモン部分であるhostap-daemonのレシピです。以下が、ここでの改造の対象となるhostap-daemonのレシピです。
HOMEPAGE = "http://hostap.epitest.fi"
SECTION = "kernel/userland"
LICENSE = "GPLv2 | BSD"
LIC_FILES_CHKSUM = "file://README;md5=4d709ce0f9c84b87d148e16731f647e1"
DEPENDS = "libnl openssl"
SUMMARY = "User space daemon for extended IEEE 802.11 management"

inherit update-rc.d
INITSCRIPT_NAME = "hostapd"


DEFAULT_PREFERENCE = "-1"

SRC_URI = " \
http://hostap.epitest.fi/releases/hostapd-${PV}.tar.gz \
file://defconfig \
file://init \
"

S = "${WORKDIR}/hostapd-${PV}/hostapd"


do_configure() {
install -m 0644 ${WORKDIR}/defconfig ${S}/.config
}

do_compile() {
export CFLAGS="-MMD -O2 -Wall -g -I${STAGING_INCDIR}/libnl3"
make
}

do_install() {
install -d ${D}${sbindir} ${D}${sysconfdir}/init.d
install -m 0644 ${S}/hostapd.conf ${D}${sysconfdir}
install -m 0755 ${S}/hostapd ${D}${sbindir}
install -m 0755 ${S}/hostapd_cli ${D}${sbindir}
install -m 755 ${WORKDIR}/init ${D}${sysconfdir}/init.d/hostapd
}

CONFFILES_${PN} += "${sysconfdir}/hostapd.conf"

SRC_URI[md5sum] = "236247a7bbd4f60d5fa3e99849d1ffc9"
SRC_URI[sha256sum] = "002e9dcb7e46cf82b5900a2fcf92b30fc8cdfd32a72d7fd4488588f1c013dfcc"

そして、上のhostap-daemonのレシピを改造するために、今回作成した拡張レシピを以下に示します。
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"

SRC_URI += "file://hostapd.conf-kronus9"

do_install_append () {
install -d ${D}${sysconfdir}
install -m 0644 ${WORKDIR}/hostapd.conf-kronus9 ${D}${sysconfdir}/hostapd.conf
}

いままで特に区別せずに、.bbと.bbappendのどちらもレシピファイルと呼んできましたが、この2つのファイルは役割が異なっています。bbがレシピ本体の定義を含み、bbappendの方は既存のレシピに対する拡張定義として働きます。bb + bbappendで一つのレシピを構成している考えれば解かり易いでしょう。ただし、レシピの名前とバージョンは一致している必要があります。例えば、hostap-daemon_1.0.bbappendというファイルを作成した場合、このファイルはhostap-daemon_1.0.bbに適用される拡張レシピ定義が記述されていると、bitbakeコマンドによって解釈されます。仮にhostap-daemon_1.1.bbappendというファイルを作成した場合、このファイルはhostap-daemon_1.0.bbには適用されません。既存のレシピをカスタマイズしたい場合、bbファイル側には一切変更を加えず、bbappendファイルを作成してその中に改造したい内容を記述するようにします。これはYocto Linuxのレシピ・カスタマイズの基本ルールです。なお、各レシピのbbファイルに適用されるbbappendファイルが存在するかどうかを知りたい場合は、下のコマンドによってその一覧情報を表示させることができます。
$ bitbake-layers show-appends
Parsing recipes..done.
=== Appended recipes ===
alsa-state.bb:
/home/yuhri/Yocto/poky-daisy-11.0.1/meta-yocto-bsp/recipes-bsp/alsa-state/alsa-state.bbappend
busybox_1.22.1.bb:
/home/yuhri/Yocto/poky-daisy-11.0.1/meta-kronus9/recipes-core/busybox/busybox_1.22.1.bbappend
connman_1.22.bb:
/home/yuhri/Yocto/poky-daisy-11.0.1/meta-kronus9/recipes-connectivity/connman/connman_1.22.bbappend
formfactor_0.0.bb:
/home/yuhri/Yocto/poky-daisy-11.0.1/meta-yocto-bsp/recipes-bsp/formfactor/formfactor_0.0.bbappend
/home/yuhri/Yocto/poky-daisy-11.0.1/meta-de3815tybe/recipes-bsp/formfactor/formfactor_0.0.bbappend
hostap-daemon_1.0.bb:
/home/yuhri/Yocto/poky-daisy-11.0.1/meta-kronus9/recipes-connectivity/hostapd/hostap-daemon_1.0.bbappend
init-ifupdown_1.0.bb:
/home/yuhri/Yocto/poky-daisy-11.0.1/meta-kronus9/recipes-core/init-ifupdown/init-ifupdown_1.0.bbappend
linux-yocto_3.14.bb:
/home/yuhri/Yocto/poky-daisy-11.0.1/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_3.14.bbappend
/home/yuhri/Yocto/poky-daisy-11.0.1/meta-intel/common/recipes-kernel/linux/linux-yocto_3.14.bbappend
linux-yocto_3.10.bb:
/home/yuhri/Yocto/poky-daisy-11.0.1/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_3.10.bbappend
/home/yuhri/Yocto/poky-daisy-11.0.1/meta-intel/common/recipes-kernel/linux/linux-yocto_3.10.bbappend
/home/yuhri/Yocto/poky-daisy-11.0.1/meta-de3815tybe/recipes-kernel/linux/linux-yocto_3.10.bbappend
linux-yocto-rt_3.10.bb:
/home/yuhri/Yocto/poky-daisy-11.0.1/meta-intel/common/recipes-kernel/linux/linux-yocto-rt_3.10.bbappend
linux-yocto-rt_3.14.bb:
/home/yuhri/Yocto/poky-daisy-11.0.1/meta-intel/common/recipes-kernel/linux/linux-yocto-rt_3.14.bbappend
packagegroup-core-tools-profile.bb:
/home/yuhri/Yocto/poky-daisy-11.0.1/meta-yocto-bsp/recipes-core/packagegroups/packagegroup-core-tools-profile.bbappend
psplash_git.bb:
/home/yuhri/Yocto/poky-daisy-11.0.1/meta-yocto/recipes-core/psplash/psplash_git.bbappend
xserver-xf86-config_0.1.bb:
/home/yuhri/Yocto/poky-daisy-11.0.1/meta-yocto-bsp/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend
linux-yocto_3.4.bb (skipped):
/home/yuhri/Yocto/poky-daisy-11.0.1/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_3.4.bbappend
linux-yocto-dev.bb (skipped):
/home/yuhri/Yocto/poky-daisy-11.0.1/meta-intel/common/recipes-kernel/linux/linux-yocto-dev.bbappend
uclibc_git.bb (skipped):
/home/yuhri/Yocto/poky-daisy-11.0.1/meta-yocto-bsp/recipes-core/uclibc/uclibc_git.bbappend

プログラムのコンフィグレーション設定、コンパイル・ルール、パッケージ生成方法などはすべてbbファイルの方に記述されているので、bbappendの方には追加パッチの適用方法やシステム固有の設定ファイルのインストール方法などを記述するのが一般的です(bbファイル側のすべての変数や関数を書き換えることも可能です)。上のhostap-daemon_1.0.bbappendに「SRC_URI += ...」という変数と「do_install_append」という関数が記述されていますが、前者はhostap-daemon_1.0.bb側に存在する「SRC_URI」変数へ値を追加し、後者は同ファイルに存在する「do_install」関数への追加処理コードとして働きます。

上記のhostap-daemon_1.0.bbappendでは、「install」コマンドによってhostapd.conf-kronus9というファイルをhostapd.confにリネームしながらパッケージへ追加しています。ターゲットシステム上では/etc/hostapd.confに配置されますが、このファイルは以下のような内容になっています。
ctrl_interface=/var/run/hostapd
interface=wlan0
driver=nl80211
ssid=kronus9-ap
wps_pin_requests=/var/run/hostapd_wps_pin_requests
wps_state=2
ap_setup_locked=0
ap_pin=69691515
eapol_key_index_workaround=0
eap_server=0
macaddr_acl=0
auth_algs=1
ignore_broadcast_ssid=0
wpa=3
wpa_key_mgmt=WPA-PSK
wpa_pairwise=CCMP
rsn_pairwise=CCMP
wpa_group_rekey=0
wpa_passphrase=k9141214
wmm_enabled=1
ieee80211n=1
ht_capab=[HT40-][SHORT-GI-20][SHORT-GI-40][RX-STBC1]
ieee80211d=1
country_code=JP
hw_mode=g
channel=9

このファイルに含まれているのは、hostap daemon(hostapdのデーモン・プログラム部分)の動作を制御するための設定項目です。「ssid=kronus9-ap」がWi-Fi APのSSID、「wpa_passphrase=k9141214」がパスフレーズに相当します(hostapdの配布元サイトに全設定項目の説明が記載されたサンプルhostapd.confが置かれています。また、hostapdのソースパッケージにも同ファイルが収納されています。hostapd.confの各項目の詳細についてはこれらを参照してください)。

Yocto Linuxのレシピファイルであるbbとbbappendで使われているプログラミング言語はPythonとシェルスクリプトです。レシピファイルの記述方法には色々なルールやテクニックが存在しています。これらを理解・習得すると、Yocto Linuxのシステム構成を自由自在に変えることができるようになります。こういう情報については、これからの記事でおいおい解説していきたいと思っています。

■ connmanレシピのカスタマイズ


hostap-daemonレシピの改造が終ったので、続いてconnmanのレシピを改造していきましょう。

connman(Connection Manage)はIntelとNokiaが共同で開発したソフトウェアで、inetdやxinetdに代わってネッワークマネージャとして働きます。Yocto LinuxだけでなくTizen, OpenELEC, Saifish OSでも採用されています。connmanはWi-Fiだけでなく、Ethernet, Bluetooth, 3G, WiMAX、そしてVPNまで管理できる優れ物のネッワークマネージャです。

以下に、Wi-Fi APシステム用のconnmanレシピの改造内容を示します。
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"

SRC_URI_de3815tybe-ap += "file://main.conf"

do_install_append_de3815tybe-ap () {
install -d ${D}${sysconfdir}/connman
install -m 0644 ${WORKDIR}/main.conf ${D}${sysconfdir}/connman/main.conf
}

上のレシピに記述されているのは、ターゲットシステムに/etc/connman/main.confというファイルを作成する処理だけです。このファイルの内容を下に示します。
[General]
NetworkInterfaceBlacklist=mon.wlan,wlan

一連の作業の最初の方で、DE3815TYKHE BSPのlinux-yocto_3.10.bbappendにWi-Fi AP用のカーネル・コンフィグレーション設定を追加しましたが、この変更によって、ターゲットシステム上でカーネルの起動時に「mon.wlan0」と「wlan0」という2つのデバイスが生成されます。この2つのデバイスをconnmanの管理から外すのが、上のmain.confの役割です。connmanの無線LANインターフェース管理機能はwpa-supplicant経由で動作しますが、これはWi-Fi端末(無線LAN子機)側専用の機能です。Wi-Fi AP(無線LAN親機)では、mon.wlan0とwlan0デバイスはhostapdによって管理されなればなりません。connmanとhostapdの無線LANインターフェース管理機能はバッティングしてしまうので、前者を活かしておくと後者は正常に動作しなくなります。

なお、上のレシピで使われている一つのテクニックについて解説しておきましょう。connman_1.22.bbappend内の「SRC_URI_de3815tybe-ap += 」と「do_install_append_de3815tybe-ap」という2つの記述と、main.confファイルのconnman/connman/de3815tybe-ap/main.confという配置に注目してください。このようにすると、上のconnman_1.22.bbappendはターゲット「de3815tybe-ap」に対してのみ適用されるようになります。複数のターゲット向けにシステムを構築していて、ターゲット別に特定のパッケージのコンフィグレーションや設定ファイルの内容を変えたい場合は、この方法を使うと対応できます。Yocto Linuxではこのテクニックがあちらこちらのレシピで使われおり、もっとも利用頻度の高いテクニックの一つになっています。

■ init-ifupdownレシピのカスタマイズ


hostap-daemonとconnmanのレシピを改造しましたが、Wi-Fi APシステムでは、これ以外に2つほど改造しなればならないパッケージがあります。init-ifupdownとbusyboxがそれです。

先にinit-ifupdownレシピの拡張定義の内容を以下に示します。
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"

hostap-daemonとconnmanには「SRC_URI += 」と「do_install_append 」という記述が存在しましたが、上のレシピにはどちらも存在しましせん。それでも生成されるパッケージ内のinterfaces(ターゲットシステムの/etc/network/interfaces)はinit-ifupdown/init-ifupdown/de3815tybe-ap/interfacesの内容に書き換えられます。なぜかというと、上のinit-ifupdown_1.0.bbappendの拡張対象となるinit-ifupdown_1.0.bbが以下のような内容だからです。
SUMMARY = "Basic TCP/IP networking init scripts and configuration files"
DESCRIPTION = "This package provides high level tools to configure network interfaces"
HOMEPAGE = "http://packages.debian.org/ifupdown"
SECTION = "base"
LICENSE = "GPLv2"
LIC_FILES_CHKSUM = "file://${WORKDIR}/copyright;md5=3dd6192d306f582dee7687da3d8748ab"
PR = "r7"

inherit update-rc.d

INITSCRIPT_NAME = "networking"
INITSCRIPT_PARAMS = "start 01 2 3 4 5 . stop 80 0 6 1 ."

SRC_URI = "file://copyright \
file://init \
file://interfaces \
file://nfsroot"

do_install () {
install -d ${D}${sysconfdir}/init.d \
${D}${sysconfdir}/network/if-pre-up.d \
${D}${sysconfdir}/network/if-up.d \
${D}${sysconfdir}/network/if-down.d \
${D}${sysconfdir}/network/if-post-down.d
install -m 0755 ${WORKDIR}/init ${D}${sysconfdir}/init.d/networking
install -m 0644 ${WORKDIR}/interfaces ${D}${sysconfdir}/network/interfaces
install -m 0755 ${WORKDIR}/nfsroot ${D}${sysconfdir}/network/if-pre-up.d
}

do_install_append_qemuall () {
# Disable network manager on machines that commonly do NFS booting
touch ${D}${sysconfdir}/network/nm-disabled-eth0
}

PACKAGE_ARCH_qemuall = "${MACHINE_ARCH}"
RDEPENDS_${PN} = "netbase"
RCONFLICTS_${PN} = "netbase (< 1:5.0)"

CONFFILES_${PN} = "${sysconfdir}/network/interfaces"

変数「SRC_URI = "..."」の設定値に「file://interfaces」が含まりており、かつ関数「do_install」の処理コードにも「install -m 0644 ${WORKDIR}/interfaces ${D}${sysconfdir}/network/interfaces」という記述が存在しています。これらが存在しているおかげで、init-ifupdown_1.0.bbappend側に同じ記述を書く必要はなくなります。

init-ifupdown_1.0.bbappendによってパッケージに組み込まれるinterfacesは、以下のような内容です。
# /etc/network/interfaces -- configuration file for ifup(8), ifdown(8)

# The loopback interface
auto lo
iface lo inet loopback

# Wireless interfaces
auto wlan0
iface wlan0 inet static
address 192.168.100.1
netmask 255.255.255.0
network 192.168.100.0
post-up iptables -t nat -A POSTROUTING -o eth0 -s 192.168.100.0/24 -j MASQUERADE
pre-down iptables -t nat -D POSTROUTING -o eth0 -s 192.168.100.0/24 -j MASQUERADE

# Wired or wireless interfaces
auto eth0
iface eth0 inet dhcp

上では、wlan0インターフェースにスタティックIPアドレスを割り当てています。そして、iptablesコマンドを使って、NATテーブルへeth0とwlan0間のIPマスカレード転送ルールを追加しています。これは、Wi-Fi APを無線LANルーターとして動作させるために必要な設定です。

■ busyboxレシピのカスタマイズ


hostap-daemon, connman, init-ifupdownのレシピを改造してきましたが、いよいよ最後です。busyboxのレシピを改造します。

以下に、busyboxレシピに対するbbappendの定義と、これによってパッケージへ追加されるudhcpd.confファイル(ターゲットシステム上の/etc/udhcpd.conf)の内容を示します。
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"

SRC_URI_de3815tybe-ap += "file://udhcpd.conf"

do_install_append_de3815tybe-ap () {
install -d ${D}${sysconfdir}
install -m 0644 ${WORKDIR}/udhcpd.conf ${D}${sysconfdir}/udhcpd.conf

echo "net.ipv4.ip_forward = 1" >> ${D}${sysconfdir}/sysctl.conf
}

start 192.168.100.10
end 192.168.100.100
interface wlan0
opt dns 9.9.9.9 6.6.6.6
opt subnet 255.255.255.0
opt router 192.168.100.1
opt lease 864000

udhcpd.confはudhcpd(busyboxのDHCPデーモン)によって参照される設定ファイルです。このファイル内の項目のうち、「opt router 」のIPアドレスはwlan0インターフェースのスタティックIPアドレスと一致していなければなりません。

また、上のbusybox_1.22.1.bbappendの中でsysctl.conf(ターゲットシステム上の/etc/sysctl.conf)に設定を追加していますが、これはIPフォワーディング処理を有効にするための設定です。この設定を有効にしておかないと、/etc/network/interfacesでNATテーブルに転送ルールを追加しても、IP層でのパケット転送は行われません。

■ Wi-Fi AP用イメージのビルド


長々と説明してきましたが、やっとこれでレシピのカスタマイズがすべて終了しました。それでは、Wi-Fi APシステム用のイメージをビルドしてみましょう。meta-kronus9レイヤにWi-Fi AP用のkronus9-image-wifiapというイメージレシピを追加したので、これを使ってターゲットイメージをビルドします。

新しいレイヤに格納されているレシピを使うので、ビルドを行う前に、bblayers.confに以下のような変更を加えておく必要があります。
# LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
LCONF_VERSION = "6"

BBPATH = "${TOPDIR}"
BBFILES ?= ""

BBLAYERS ?= " \
/home/yuhri/Yocto/poky-daisy-11.0.1/meta \
/home/yuhri/Yocto/poky-daisy-11.0.1/meta-yocto \
/home/yuhri/Yocto/poky-daisy-11.0.1/meta-yocto-bsp \
/home/yuhri/Yocto/poky-daisy-11.0.1/meta-openembedded/meta-oe \
/home/yuhri/Yocto/poky-daisy-11.0.1/meta-intel \
/home/yuhri/Yocto/poky-daisy-11.0.1/meta-de3815tybe \
/home/yuhri/Yocto/poky-daisy-11.0.1/meta-kronus9 \
"
BBLAYERS_NON_REMOVABLE ?= " \
/home/yuhri/Yocto/poky-daisy-11.0.1/meta \
/home/yuhri/Yocto/poky-daisy-11.0.1/meta-yocto \
"

そして、local.confにも以下のような変更と設定を追加します。
# This sets the default machine to be qemux86 if no other machine is selected:
MACHINE ?= "de3815tybe-ap"
MACHINE ??= "valleyisland-64"

#
# DE3815TYBE Wi-Fi AP configuration
#
PACKAGECONFIG_remove_pn-connman = "wifi bluetooth 3g"

上の「PACKAGECONFIG_remove_pn-connman」には説明が必要でしょうね。これは、connmanのビルド時に適用されるコンフィグレーションを変更するための設定です。デフォルトでは、connmanのビルド・コンフィグレーションは「PACKAGECONFIG = "wispr wifi bluetooth 3g"」とconnman_1.22.bb内に定義されているので、この設定値から「"wifi bluetooth 3g"」を除外するために、上のような設定をlocal.confに追加しています。bbファイル内に変数PACKAGECONFIGが定義されていることが条件になりますが、「PACKAGECONFIG_remove_pn-<PACKAGE_NAME>」という変数を使って、その設定値を変更することができます。なお、この設定定義はconnman_1.22.bbappendの方に記述しても構いません。その場合は、「PACKAGECONFIG_remove」という変数名を使います。local.conf側に記述している理由は、ターゲットのハード構成が変わったときにconnman_1.22.bbappend側を変更しなくて済むからです。

それでは、最後にWi-Fi APシステム用イメージのビルドをやってみましょう。ビルド方法は他のイメージと同じです。以下のコマンドを実行すると、kronus9-image-wifiapイメージをビルドできます。
$ bitbake kronus9-image-wifiap -c fetchall
$ bitbake kronus9-image-wifiap

エラーが起きずにビルドが通れば、kronus9-image-wifiap-de3815tybe-ap.hddimgという名前のhddimgファイルが生成されます。以下のコマンドを実行すれば、このファイルからLive USBメディアを作成できます。
$ umount /dev/sdc
$ sudo dd if=tmp/deploy/images/de3815tybe-ap/kronus9-image-wifiap-de3815tybe-ap.hddimg of=/dev/sdc
$ sync

このUSBメディアを使ってDE3815TYKHEでYocto Linuxを起動すると、起動後のifconfigコマンドの出力情報は以下のようになっているはずです。
# ifconfig
eth0 Link encap:Ethernet HWaddr xx:xx:xx:xx:xx:xx
inet addr:192.168.233.9 Bcast:192.168.233.255 Mask:255.255.255.0
inet6 addr: fe80::xxxx:xxff:fexx:xxxx/64 Scope:Link
UP BROADCAST RUNNING MULTICAST DYNAMIC MTU:1500 Metric:1
RX packets:6 errors:0 dropped:0 overruns:0 frame:0
TX packets:16 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1177 (1.1 KiB) TX bytes:3072 (3.0 KiB)

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:10 errors:0 dropped:0 overruns:0 frame:0
TX packets:10 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:700 (700.0 B) TX bytes:700 (700.0 B)

mon.wlan0 Link encap:UNSPEC HWaddr xx-xx-xx-xx-xx-xx-30-00-00-00-00-00-00-00-00-00
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:12 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:3798 (3.7 KiB) TX bytes:0 (0.0 B)

wlan0 Link encap:Ethernet HWaddr xx:xx:xx:xx:xx:xx
inet addr:192.168.100.1 Bcast:192.168.100.255 Mask:255.255.255.0
inet6 addr: fe80::xxxx:xxff:fexx:xxxx/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:21 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:3772 (3.6 KiB)


ここで、Wi-Fi機能を搭載しているノートPC、スマホ、タブレットなどからDE3815TYKHEへ接続してみましょう。そして、Webブラウザで適当なサイトのページを開いてみてください。問題なくページが表示されれば、DE3815TYKHEはWi-Fi APとして正常に動作していることになります。

これで本記事はお終いです。DE3815TYKHEのWi-Fiアクセスポイント化を題材にして、BSPへのターゲット定義の追加方法、レイヤの作成方法、イメージレシピの作成方法、さらにパッケージレシピのカスタマイズ方法について解説しましたが、いかがでしたでしょうか。Yocto Linuxに取り組み始めたばかりのビギナーにはちょっと難易度が高かったかもしれませんが、それでも手も足も出ないほどの世界ではなさそうだと感じてもらえたら良いなぁと思いながら本記事を書きました。そう言う私も、Yocto Linuxの研究に取り組み始めた当初はその世界観になかなか馴染めませんでした。しかし、地道にたくさんのレシピを読み解いていくと、あちらこちらにテクニックのヒントやTipsが存在していることに気づきました。そして、ちゃんと仕組みが理解できてくると、自由自在にシステムを構築できそうだと思えるようになりました。Yocto Linuxは本当によく出来たディストリビューションです。本業の仕事でフルタイムでYocto Linuxの研究開発をやっているのも大きいですが、私は2ヶ月程度でYocto Linuxのあらゆる部分を弄くり回せるようになりました(カーネル移植、ミドルウェア移植、ドライバ/アプリ開発、システム構築など組込みLinuxの豊富な経験を持っていたことも効いています)。いまではYocto Linuxのすばらしさに惚れ込んでいます。そして、私はやっぱり組込みLinuxがとことん好きなんだなぁと自覚しました。

ハードだけでなくソフトについても、やはりIntelの技術力はスゴイなぁーと実感しています。Yocto Projectもそうですが、Intelが主導者的な役割をしているプロジェクトやソフトウェアを研究すると、技術的に得るものが本当に大きいです(Intelには世界トップクラスの技術者が集まっているんだから、これは当然ですが)。例えば、画像認識でもっとも広く使われているOpenCVも元はIntelが開発・公開したソフトです。このようにIntelがオリジナルを開発して、いまでは特定の分野でメジャーな存在になっているソフトはたくさんあります。組込みLinuxに興味を持っていて、Raspberry Piみたいなボードでちょこっと動作確認をやる程度では飽き足らず、さらに深くやってみたいと思っている方がいれば、ぜひYocto Linuxに挑戦しみることをお勧めします。きっと新世界が観えてきて、組込みLinuxのすばらしさを再認識できるでしょう。

【参考ページ】

 hostapd - Linux Wireless
 Software access point - ArchWiki
 How to Set up a Raspberry Pi as a Wireless Access Point
posted by とみやん at 13:15| Comment(0) | TrackBack(0) | Embedded Linux > Yocto Project

2014年11月28日

[Yocto] DE3815TYKHEへのWi-Fi端末機能追加

最近組込み分野におけるYocto Projectの存在感は益々大きくなってきています。IntelはYocto Projectを積極的に後押しており、かなり大きな開発リソースを投入しています。また、Intelは組込み向けの新しいプロセッサや評価ボードなどを次々と発表していますが、組込みOSとしてYocto ProjectとAndroidを強力にプッシュしています。Wind Riverなどの組込みLinuxのベンダー企業もYocto Projectに積極的に開発リソースを投入しているようです。ここに来て、Yocto Projectを取り巻く動きはさらに活発になっています。

前記事では、DE3815TYKHEの内蔵EthernetコントローラであるRealtek RTL8111のドライバをYocto Linuxへ追加する方法について書きました。Valley Island(Intel E38xx)用BSPをカスタマイズすることで目的を達成しましたが、新しいターゲット・ハードウェアへYocto Linuxを移植する場合、既存のBSPを改造することが手っ取り早い方法です。Yocto Linuxに取り組むプログラマが増えているようなので、BSPのカスタマイズ方法に関する導入ガイド的な情報として、前記事は役に立つ内容になっているのではないかと自負しています。本業の仕事でもYocto Linuxの研究開発に携わっていますが、休日などのプライベートな時間もYocto Linuxの研究に相当な時間を割いています。仕事上必要に迫られてYocto Projectについてググって調べることが多いですが、日本語の情報はまだまだ少ないのが実情です。オープンソース・コミュニティへの貢献にもなるので、プライベートな研究活動で得られた成果や情報を積極的に公開していこうと思っています(本業の仕事があまりに忙しすぎて、記事を書く時間がなかなか取れないのが悩みですが・・・)。

さて、10/13の記事でDE3815TYKHEへSO-DIMMメモリとSSDを組み込む作業について書きましたが、DE3815TYKHEにはMini-PCIeスロットと無線LAN用のアンテナ・ケーブルが内蔵されていました。せっかくスロットが内蔵されているのに使わないのはもったいないので、DE3815TYKHEへ無線LANカードを追加してみました。同時にYocto LinuxへWi-Fi端末機能を追加する作業も行ったので、その作業の詳細についても書きます。

■ DE3815TYKHEへの無線LANカードの組込み


今回入手したのはRalink RT3090というチップを搭載した無線LANカードです。このチップはIEEE802.11b/g/nの無線通信規格に対応しています。
ANIMG_20141127_084730-DE3815TYKHE-Embedding_WLAN-Ralink_RT3090.jpg
ANIMG_20141127_085658-DE3815TYKHE-Embedding_WLAN-Ralink_RT3090.jpg
まずは、DE3815TYKHEへの無線カードの組み込みから始めました。組み込み作業は簡単でした。内蔵のMini-PCIeスロットにカードを挿して、カード上の2つのコネクタにアンテナ・ケーブルを取り付けるだけです。
ANIMG_20141129_155541-DE3815TYKHE_Embedding_WLAN-Ralink_RT3090.jpg
なお、上の写真のとおり、本無線カードは技術基準適合証明(いわゆる「技適マーク」)を取得済みの物なので、屋外や正式な稼働現場でも無線機能内蔵機器として使うことができますが、技適マークの付いていない無線カードを組み込んだ機器を屋外や正式な稼働現場などで使用することは違法です(屋内限定の実験レベルでの使用なら電波法に抵触しないという解釈もあるようですが、この辺は曖昧みいたいです)。無線カードを機器に組み込んで使う場合は、この点に注意しなければなりません。

■ DE3815TYKHE BSPへのWi-Fi設定追加


無線カードの組み込み作業が済んだので、さっそくDE3815TYKHEでYocto Linuxを起動してみました。そして、PCI/PCIeボードを追加したときの定番コマンドであるlspciコマンドを最初に実行してみました。無線LANカードを挿した状態でのlspciコマンドの出力情報は下のようになりました。
# lspci
00:00.0 Host bridge: Intel Corporation ValleyView SSA-CUnit (rev 0c)
00:02.0 VGA compatible controller: Intel Corporation ValleyView Gen7 (rev 0c)
00:13.0 SATA controller: Intel Corporation ValleyView 6-Port SATA AHCI Controller (rev 0c)
00:14.0 USB controller: Intel Corporation ValleyView USB xHCI Host Controller (rev 0c)
00:1a.0 Encryption controller: Intel Corporation ValleyView SEC (rev 0c)
00:1b.0 Audio device: Intel Corporation ValleyView High Definition Audio Controller (rev 0c)
00:1c.0 PCI bridge: Intel Corporation ValleyView PCI Express Root Port (rev 0c)
00:1c.1 PCI bridge: Intel Corporation ValleyView PCI Express Root Port (rev 0c)
00:1c.2 PCI bridge: Intel Corporation ValleyView PCI Express Root Port (rev 0c)
00:1f.0 ISA bridge: Intel Corporation ValleyView Power Control Unit (rev 0c)
00:1f.3 SMBus: Intel Corporation ValleyView SMBus Controller (rev 0c)
02:00.0 Network controller: Ralink corp. RT3090 Wireless 802.11n 1T/1R PCIe
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0c)

PCIバス・レベルでカードは認識されていますが、ifconfigコマンドで情報を取得しても、無線LANのインスターフェースは存在していませんでした。カーネルにRalink RT3090用のドライバを組み込んでいないので当然です。dmesgコマンドの情報でも、それらしいドライバはロードされていませんでした。それでは、Yocto Linuxに無線LANドライバを組み込むにはどうすれば良いのでしょうか。

本件に関する情報が欲しくて、Yocto Projectの公式サイトのページを探し回ったり同プロジェクトのGitリポジトリに存在するレシピなどを片っ端から読んだりしました。結論を先に書くと、前記事で作成したDE3815TYKHE用BSPに以下のような変更を加えると、Yocto LinuxへWi-Fi機能を組み込むことができます(ターゲット名を「de3815tyke」から「de3815tybe」に変更しました。その関係で、前記事からファイル名を変更しています。ちなみに、「DE3815TYBE」はDE3815TYKHEに搭載されているボードの型番です。Intelは本ボードを単独でも販売しています)。
#@TYPE: Machine
#@NAME: Intel DE3815TYBE (Thin Canyon) board which is embedded in NUC Kit DE3815TYKHE

#@WEBTITLE: Intel Atom E38xx Processor (DE3815TYBE) 32-bit with Open Source Frame Buffer Graphics

#@DESCRIPTION: Machine configuration for DE3815TYBE 32-bit systems, without Intel-proprietary graphics bits

PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
PREFERRED_VERSION_linux-yocto ?= "3.10%"

require conf/machine/include/intel-core2-32-common.inc
require conf/machine/include/intel-common-pkgarch.inc
require conf/machine/include/meta-intel.inc

MACHINE_FEATURES += "pcbios efi"
MACHINE_FEATURES += "wifi"

MACHINE_EXTRA_RRECOMMENDS += "linux-firmware"

XSERVER ?= "${XSERVER_X86_BASE} \
${XSERVER_X86_EXT} \
${XSERVER_X86_FBDEV} \
${XSERVER_X86_I965} \
"

APPEND += "acpi_enforce_resources=lax video=efifb:off vga=0x318"

#@TYPE: Machine
#@NAME: Intel DE3815TYBE (Thin Canyon) board which is embedded in NUC Kit DE3815TYKHE

#@WEBTITLE: Intel Atom E38xx Processor (DE3815TYBE) 64-bit with Open Source Frame Buffer Graphics

#@DESCRIPTION: Machine configuration for DE3815TYBE 64-bit systems, without Intel-proprietary graphics bits

PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
PREFERRED_VERSION_linux-yocto ?= "3.10%"

require conf/machine/include/intel-corei7-64-common.inc
require conf/machine/include/intel-common-pkgarch.inc
require conf/machine/include/meta-intel.inc

MACHINE_FEATURES += "pcbios efi"
MACHINE_FEATURES += "wifi"

MACHINE_EXTRA_RRECOMMENDS += "linux-firmware"

XSERVER ?= "${XSERVER_X86_BASE} \
${XSERVER_X86_EXT} \
${XSERVER_X86_FBDEV} \
${XSERVER_X86_I965} \
"

APPEND += "acpi_enforce_resources=lax video=efifb:off vga=0x318"

FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"

#############################
# MACHINE = de3815tybe-32 #
#############################
COMPATIBLE_MACHINE_de3815tybe-32 = "de3815tybe-32"
KMACHINE_de3815tybe-32 = "valleyisland-32"
KBRANCH_de3815tybe-32 = "standard/base"
KERNEL_FEATURES_de3815tybe-32 = " features/valleyisland-io/valleyisland-io \
features/valleyisland-io/valleyisland-io-pci.scc \
features/wifi/wifi-all.scc"

LINUX_VERSION_de3815tybe-32 = "3.10.43"
SRCREV_machine_de3815tybe-32 = "aa677a2d02677ec92d59a8c36d001cf2f5cf3260"
SRCREV_meta_de3815tybe-32 = "199943142f7e0a283240246ee6c02f4376b315f0"
SRCREV_valleyisland-io_de3815tybe-32 = "27bc40c174bb4ca160eafd6ccf3da9e774c9a8c7"

SRC_URI_de3815tybe-32 = "git://git.yoctoproject.org/linux-yocto-3.10.git;protocol=git;nocheckout=1;branch=${KBRANCH},${KMETA},valleyisland-io-2.0;name=machine,meta,valleyisland-io"

SRC_URI_de3815tybe-32 += "file://add_driver-net_ethernet_r8169.cfg"

#############################
# MACHINE = de3815tybe-64 #
#############################
COMPATIBLE_MACHINE_de3815tybe-64 = "de3815tybe-64"
KMACHINE_de3815tybe-64 = "valleyisland"
KBRANCH_de3815tybe-64 = "standard/base"
KERNEL_FEATURES_de3815tybe-64 = " features/valleyisland-io/valleyisland-io \
features/valleyisland-io/valleyisland-io-pci.scc \
features/wifi/wifi-all.scc"

LINUX_VERSION_de3815tybe-64 = "3.10.43"
SRCREV_machine_de3815tybe-64 = "aa677a2d02677ec92d59a8c36d001cf2f5cf3260"
SRCREV_meta_de3815tybe-64 = "199943142f7e0a283240246ee6c02f4376b315f0"
SRCREV_valleyisland-io_de3815tybe-64 = "27bc40c174bb4ca160eafd6ccf3da9e774c9a8c7"

SRC_URI_de3815tybe-64 = "git://git.yoctoproject.org/linux-yocto-3.10.git;protocol=git;nocheckout=1;branch=${KBRANCH},${KMETA},valleyisland-io-2.0;name=machine,meta,valleyisland-io"

SRC_URI_de3815tybe-64 += "file://add_driver-net_ethernet_r8169.cfg"

module_autoload_i2c-dev = "i2c-dev"

Yocto LinuxへWi-Fi(無線LAN)端末機能を追加するために必要な変更はたったこれだけです。linux-yocto_3.10.bbappendに加えた変更によって、カーネルのソースツリーに存在する主要な無線LANドライバがすべて組み込まれます。一方、de3815tybe-32.confde3815tybe-64.confの変更内容は、ターゲットイメージへWi-Fi関連パッケージを追加する役割を持っています。後者の変更によって、以下のパッケージがターゲットイメージへ組み込まれます。
  • linux-firmware-*
  • wireless-tools
  • wpa-supplicant
  • connman-gnome

「linux-firmware-」という名前で始まるパッケージには無線LANチップのファームウェアがバイナリ形式で格納されており、チップの種類分数が存在します。無線LANチップのファームウェアはデバイス・メーカーから配布されており、git.kernel.orgに収集されています(ファームウェアを公開していないメーカーも存在します。その場合は、有志の独自調査によりファームウェアを作成しているようです)。このサイトからダウンロードしたファームウェアから各無線LANチップ用のlinux-firmwareパッケージが生成されます。無線LANドライバがチップの初期化時にファームウェアをカードへロードする仕組みになっており、対象チップに適合したファームウェアが存在しないと、無線LANカードは正常に動作しません。上の「MACHINE_EXTRA_RRECOMMENDS += "linux-firmware"」という設定によって、主要な無線LANチップ用のlinux-firmwareパッケージがすべてターゲットイメージへ組み込まれます。

■ connman-gnomeによるWi-Fi接続


DE3815TYKHE BSPに上の変更を加えた後、以下のコマンドによってカーネルとターゲットイメージの再ビルドを行えば、Yocto LinuxへWi-Fi端末機能が追加されます。
$ bitbake linux-yocto -c cleansstate
$ bitbake linux-yocto
$ bitbake core-image-sato

上記の変更を加えたBSPから再ビルドしたYocto LinuxをDE3815TYKHEで起動すると、dmesgコマンドの出力情報に下のような行が追加されます。
# dmesg
.... ....
.... ....
.... ....
.... ....
[ 1.746796] cfg80211: Calling CRDA to update world regulatory domain
.... ....
[ 1.909116] rt2800pci 0000:02:00.0: enabling device (0000 -> 0002)
[ 1.915002] ieee80211 phy0: rt2x00_set_rt: Info - RT chipset 3090, rev 3213 detected
[ 1.966563] ieee80211 phy0: rt2x00_set_rf: Info - RF chipset 0005 detected
[ 2.201021] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
.... ....

これでRalink RT3090用のドライバはロードされチップの初期化は行われていますが、この段階でifconfigコマンドを実行しても、無線LANのインターフェースは存在していません。その理由は、Yocto Linuxのネットワーク・インターフェースはconnman(Connection Manager)というソフトウェアによって管理されているからです。connmanによっていずれかのWi-Fiアクセスポイントに接続した段階で、初めて無線LANのインターフェースが作成されます。

core-image-sato(Sato Mobile Desktop)イメージでYocto Linuxを起動している場合、具体的には、以下のような操作を行う必要があります。
  1. Sato Mobile Desktop画面の右上に存在するLANケーブルのアイコンをクリックすると、下のようなメニューが表示されます。
    UBShot_20141202_154430-DE3815TYKHE-connman-gnome-WiFi_Setup-1024x768
    このメニューから[Preferences]メニューを選択します。

  2. すると、下のようなウィンドウが開きます。これがGUI版Connection Manager(connman-gnome)の画面です。
    UBShot_20141202_154506-DE3815TYKHE-connman-gnome-WiFi_Setup-1024x768
    上は、左側のServicesリストから[Wireless Networks]を選択したときのウィンドウ表示です。

    このウィンドウの[Enable]ボタンを押すと、無線LANインターフェースが有効になります。同時にWi-Fiアクセスポイントの検索処理が行われ、数秒後にServicesリスト内の[Wireless Networks]の下に見つかったアクセスポイントのSSIDの一覧が表示されます。
    UBShot_20141202_154705-DE3815TYKHE-connman-gnome-WiFi_Setup-1024x768
    なお、無線LANインターフェースが有効な状態で[Scan]ボタンを押すと、アクセスポイントの再検索を行うことができます。

  3. SSIDのリストから、接続したいアクセスポイントを選択してください。すると、下のようなウィンドウ表示に変わります。
    UBShot_20141202_154725-DE3815TYKHE-connman-gnome-WiFi_Setup-1024x768
    このウィンドウの[Connect]ボタンを押すと、下のようなポップアップ・ウィンドウが表示されます。
    UBShot_20141202_154918-DE3815TYKHE-connman-gnome-WiFi_Setup-1024x768
    このウィンドウの[Passphrase]エディットボックスに、接続しようとしているアクセスポイントのパスフレーズ(共有キー)を入力して、[OK]ボタンを押してください。

  4. アクセスポイントへの接続処理が実行され、上で入力したパスフレーズが正しければ、Servicesリストの対象SSIDの下に「connected」という表示が追加されます(接続処理の進行によって、この表示は「associating...」→「configuring...」→「connected」と変化します)。
    UBShot_20141202_155059-DE3815TYKHE-connman-gnome-WiFi_Setup-1024x768
    上のような状態になれば、アクセスポイントへの接続は完了しています。

上の操作を行った後、ターミナルからifconfigコマンドを実行すると、wlan0というインターフェースが作成されているはずです。これが無線LANのネットワーク・インターフェースです。
# ifconfig
eth0 Link encap:Ethernet HWaddr XX:XX:XX:XX:XX:XX
inet addr:192.168.223.9 Bcast:192.168.223.255 Mask:255.255.255.0
inet6 addr: fe80::xxxx:xxff:fexx:xxxx/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1220 errors:0 dropped:0 overruns:0 frame:0
TX packets:616 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:92049 (89.8 KiB) TX bytes:492673 (481.1 KiB)

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:12 errors:0 dropped:0 overruns:0 frame:0
TX packets:12 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:660 (660.0 B) TX bytes:660 (660.0 B)

wlan0 Link encap:Ethernet HWaddr XX:XX:XX:XX:XX:XX
inet addr:192.168.179.6 Bcast:192.168.179.255 Mask:255.255.255.0
inet6 addr: fe80::xxxx:xxff:fexx:xxxx/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:39 errors:0 dropped:0 overruns:0 frame:0
TX packets:59 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2005 (1.9 KiB) TX bytes:9075 (8.8 KiB)


また、connmanによる無線LANインターフェースの有効化とアクセスポイントへの接続操作を行うと、下のようなカーネルログも出力されます。
# dmesg
.... ....
.... ....
[ 35.727187] ieee80211 phy0: rt2x00lib_request_firmware: Info - Loading firmware file 'rt2860.bin' 'rt2860.bin'
[ 35.732481] ieee80211 phy0: rt2x00lib_request_firmware: Info - Firmware detected - version: 0.34
[ 35.778497] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 66.643277] wlan0: authenticate with xx:xx:xx:xx:xx:xx
[ 66.652945] wlan0: send auth to xx:xx:xx:xx:xx:xx (try 1/3)
[ 66.654514] wlan0: authenticated
[ 66.655252] wlan0: associate with xx:xx:xx:xx:xx:xx (try 1/3)
[ 66.662697] wlan0: RX AssocResp from xx:xx:xx:xx:xx:xx (capab=0x431 status=0 aid=1)
[ 66.662811] wlan0: associated
[ 66.662860] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready

connmanで接続したアクセスポイントを経由してインターネットにアクセスできるかどうか試すには、ターミナルから下のようなpingコマンドを実行してみると良いでしょう。
# ping www.yoctoproject.org
PING www.yoctoproject.org (140.211.169.56): 56 data bytes
64 bytes from 140.211.169.56: seq=0 ttl=48 time=156.630 ms
64 bytes from 140.211.169.56: seq=1 ttl=48 time=156.535 ms
64 bytes from 140.211.169.56: seq=2 ttl=48 time=156.484 ms
64 bytes from 140.211.169.56: seq=3 ttl=48 time=156.374 ms
64 bytes from 140.211.169.56: seq=4 ttl=48 time=156.321 ms
64 bytes from 140.211.169.56: seq=5 ttl=48 time=156.516 ms

ただし、Ethernet側のLANケーブルを外した状態で行うべきです。Ethernet側の有線LAN回線経由ではなく、無線LAN回線経由でのインターネット接続を確認することが目的だからです。Webブラウザが在ればもっと簡単に確認できるのですが、残念ながら、デフォルトの状態ではcore-image-satoイメージにWebブラウザは組み込まれていません。

connman-gnomeによって接続したWi-Fiアクセスポイントの情報は保存されています。そのため、システムを再起動しても、自動的に前回接続していたアクセスポイントへ接続され、wlan0インターフェースが作成されます。

■ connman-clientによるCLI環境へのWi-Fi機能追加


これでYocto LinuxへのWi-Fi端末機能の組み込み作業は一応終わりですが、もう一つ補足的な情報を掲載しておきます。GUIではなくCLI環境にWi-Fi端末機能を追加する方法についてです。これまで、ずっとcore-image-sato(Sato Mobile Desktop)というGUI環境のイメージをビルドしてきましたが、Yocto LinuxにはCLI環境用のイメージレシピもいくつか収納されています。その中から、core-image-full-cmdlineというイメージにWi-Fi端末機能を組み込んでみたので、その作業の内容も紹介しておきましょう。モニタやタッチスクリーンの存在しないCLIベースのターゲット用にYocto LinuxでWi-Fi端末システムを構築するケースを想定しています。

CLI環境用イメージにWi-Fi機能を組み込む場合、BSPの内容は特に変わりはありません。上記のBSPをそのまま使うことができます。Wi-Fi関連パッケージもconnman-gnome以外はそのまま使えます。connman-gnomeだけはGUI環境用のパッケージなので使えません。connman-gnomeに代わって、connman-clientというパッケージを追加する必要があります。これはコマンドラインで動作するconnmanの接続設定アプリです。

Yocto Linuxのシステム構成イメージにパッケージを追加する方法はいくつか存在します。この辺の詳しい情報は別の記事で解説したいと思っていますが、今回は手っ取り早くlocal.confに設定記述を追加することで実現してみました。具体的には、以下のようにlocal.confを変更しました。
#
# Additional packages to be installed to the specific images
#
IMAGE_INSTALL_append_pn-core-image-full-cmdline = " \
kernel-modules \
wireless-tools \
wpa-supplicant \
connman \
connman-client"

#
# Extra image configuration defaults
#
# The EXTRA_IMAGE_FEATURES variable allows extra packages to be added to the generated
# images. Some of these options are added to certain image types automatically. The
# variable can contain the following options:
# "dbg-pkgs" - add -dbg packages for all installed packages
# (adds symbol information for debugging/profiling)
# "dev-pkgs" - add -dev packages for all installed packages
# (useful if you want to develop against libs in the image)
# "ptest-pkgs" - add -ptest packages for all ptest-enabled packages
# (useful if you want to run the package test suites)
# "tools-sdk" - add development tools (gcc, make, pkgconfig etc.)
# "tools-debug" - add debugging tools (gdb, strace)
# "eclipse-debug" - add Eclipse remote debugging support
# "tools-profile" - add profiling tools (oprofile, exmap, lttng, valgrind)
# "tools-testapps" - add useful testing tools (ts_print, aplay, arecord etc.)
# "debug-tweaks" - make an image suitable for development
# e.g. ssh root access has a blank password
# There are other application targets that can be used here too, see
# meta/classes/image.bbclass and meta/classes/core-image.bbclass for more details.
# We default to enabling the debugging tweaks.
EXTRA_IMAGE_FEATURES = "debug-tweaks package-management"

IMAGE_INSTALL_append」という変数を使うと、すべてのイメージが対象になりますが、上のように「IMAGE_INSTALL_append_pn-<IMAGE_NAME>」という変数名にすると、指定したイメージに対してのみパッケージを追加することができます。また、core-image-full-cmdlineイメージにはrpmコマンドが入っていないので、これを組み込むために「EXTRA_IMAGE_FEATURES」の設定も変更しました。rpmコマンドを使えると、後からターゲット環境へパッケージをインストールすることができます。システム構成を調べる際にも役立つので、ターゲットイメージには必ずrpmやopkgなどのパッケージ管理コマンを入れておくことをお勧めします。

core-image-full-cmdlineイメージのビルド手順はcore-image-satoと同じです。以下のコマンドによって、ビルドできます。
$ bitbake core-image-full-cmdline -c fetchall
$ bitbake core-image-full-cmdline

起動&インストール用USBメディアの作成方法も同じです。USBメモリを開発マシンへ挿した状態で、以下のコマンドを実行すれば、同メディアを作成できます。
$ umount /dev/sdc
$ sudo dd if=tmp/deploy/images/de3815tybe-64/core-image-full-cmdline-de3815tybe-64.hddimg of=/dev/sdc
$ sync

上で作成したUSBメディアを使って、DE3815TYKHEの内蔵SSDへYocto Linuxをインストールしました。その上で、内蔵SSDからYocto Linuxを再起動しました。core-image-full-cmdlineイメージでは、Yocto Projectのスプラッシュ画面に続いて、ログインプロンプトがモニタ画面に表示されます。

ログインした後ifconfigコマンドを実行すると、やはり無線LANのwlan0インターフェースは作成されていません。これはcore-image-satoと同じです。ここで、無線LANインターフェースの有効化とWi-Fiアクセスポイントへの接続操作を行います。CLI環境でこれらを行うには、「connmanctl」というコマンドを使います。具体的には、以下のような手順を実行します。
# connmanctl
connmanctl> enable wifi
Enabled wifi
connmanctl> scan wifi
Scan completed for wifi
connmanctl> agent on
Agent registered
connmanctl> services
AirPort15044 wifi_xxxxxxxxxxxx_416972506f72743135303434_managed_psk
Guest15044 wifi_xxxxxxxxxxxx_47756573743135303434_managed_psk
nad11-2e8ac2 wifi_xxxxxxxxxxxx_6e616431312d326538616332_managed_psk
ZL wifi_xxxxxxxxxxxx_5a4c_managed_psk
106F3F655F8A3 wifi_xxxxxxxxxxxx_313036463346363546384133_managed_psk
106F3F655F8A3-1 wifi_xxxxxxxxxxxx_3130364633463635463841332d31_managed_psk
TP-LINK_648426 wifi_xxxxxxxxxxxx_54502d4c494e4b5f363438343236_managed_psk
001D738E88FB-3 wifi_xxxxxxxxxxxx_3030314437333845383846422d33_managed_psk
001D738E88FB wifi_xxxxxxxxxxxx_303031443733384538384642_managed_psk
001D738E88FB-3 wifi_xxxxxxxxxxxx_3030314437333845383846422d31_managed_psk
0000docomo wifi_xxxxxxxxxxxx_30303030646f636f6d6f_managed_psk
connmanctl> connect wifi_xxxxxxxxxxxx_6e616431312d326538616332_managed_psk
Agent RequestInput wifi_xxxxxxxxxxxx_6e616431312d326538616332_managed_psk
Passphrase = [ Type=psk, Requirement=mandatory, Alternates=[ WPS ] ]
WPS = [ Type=wpspin, Requirement=alternate ]
Passphrase? ************〔← 接続対象アクセスポイントのパスフレーズ(共有キー)を入力する〕
Connected wifi_xxxxxxxxxxxx_6e616431312d326538616332_managed_psk
connmanctl> quit

上の操作を行った後ifconfigコマンドを実行すれば、無線LANのwlan0インターフェースが作成されていることが確認できます。Wi-Fiアクセスポイントへの接続が完了すれば、無線LANのネットワーク環境はSato Mobile Desktopと変わりありません。インターネットへのアクセスも問題なくできます。

【参考ページ】

 connman: wifi configuration ・ IntelOpenDesign/MakerNode Wiki ・ GitHub
 WiFi access on Intel(TM) Galileo with Yocto* Linux
 インテル Galileo 開発ボードでWi-Fi/BTを適法に使用する方法の実践 | KEI SAKAKI's PAGE.
 Connman - ArchWiki


posted by とみやん at 16:29| Comment(0) | TrackBack(0) | Embedded Linux > Yocto Project

2014年10月25日

[Yocto] BSPカスタマイズによるDE3815TYKHEのEthernet対応追加

前記事に書いたとおり、Shuttle XS36V4でYocto Linuxを動かすことはトラブルに遭遇することもなくすんなりと成功してしまいました。Valley Island BSPに収納されているバイナリ・イメージと自分でビルドしたDE3815TYKHE用のイメージの2つを使いましたが、どちらでも特に問題なくXS36V4でYocto Linuxは動作しました。Valley Island BSPはデフォルト状態でRTL8168/8169/8111/8411ドライバが有効になっていたので、ドライバを組み込むことなくEthernetインターフェースも使えました。ただし、一つ大きな課題を見つけてしまいました。それは、Yocto LinuxがXS36V4の無線LANデバイスを認識していないことです。

前記事で使ったDE3815TYKHE用のcore-image-satoイメージは、カーネルレシピに主要な無線LANドライバをすべて組み込んた状態でビルドしたものです。〔2014/12/29の記事linux-yocto_3.10.bbappendを参照〕lspciコマンドの出力情報によって、XS36V4に搭載されている無線LANデバイスはRealtek RTL8188EEという物であることが判りました。しかし、dmesgコマンドのカーネル・ログを確認しても、RTL8188EE用ドライバはロードされていませんでした。Sato Mobile DesktopのGUI画面からconnman-gnomeを起動してみましが、下のとおり、やはりServiesリストに[Wireless Networks]というカテゴリ・エントリは存在していません。
UBShot_20150113_103340-YoctoLinux-Enabling_RTL8188EE_WLAN_Driver-1366x768
どうやらRTL8188EE用の無線LANドライバがカーネルへ組み込まれていないようです。

ググって調べてみると、カーネルソース・ツリーにRTL8188EE用ドライバは存在しており、これを有効にするにはCONFIG_RTL8188EEというコンフィグレーション設定項目を有効する必要があることが判りました。現状のカーネルのコンフィグレーション設定を確認すると、やはりこの項目は有効になっていませんでした。
# zcat /proc/config.gz | grep CONFIG_RTL8188EE
# CONFIG_RTL8188EE is not set

上記の情報に基いて、XS36V4のWi-Fi機能を利用可能にする作業を行ったので、その作業記録を本記事に書きます。

■ RTL8188EE無線LANドライバの組み込み


まずは、一時的にコンフィグレーション設定を変更して、カーネルへRTL8188EEドライバを組み込む作業を行いました。

bitbake linux-yocto -c menuconfig」コマンドによってカーネルのコンフィグレーション・メニュー画面を開いて、以下のメニュー項目を有効にすれば、RTL8188EEドライバを組み込むことができます。〔2014/10/25の記事を参照〕
UBShot_20150113_115841-YoctoLinux-Enabling_RTL8188EE_WLAN_Driver-704x766
         Device Drivers  --->

[*] Nework device support --->

[*] Wireless LAN --->

<M> Realtek RTL8188EE Wireless Network Adapter

上の操作を行った後、以下のコマンドを実行して、RTL8188EEドライバを組み込んだcore-image-satoイメージを作成しました。
% bitbake linux-yocto -c compile -f
% bitbake linux-yocto -c deploy
% bitbake linux-yocto
% bitbake core-image-sato

core-image-satoのhddimgファイルからLive USBを作成して、このUSBメディアを使って、XS36V4でYocto Linuxを起動しました。そして、CONFIG_RTL8188EEが有効になっていることを確認しました。
# zcat /proc/config.gz | grep CONFIG_RTL8188EE
CONFIG_RTL8188EE=m

続いて、dmesgコマンドによってRTL8188EEドライバがロードされているかを確認しました。
# dmesg
.... ....
.... ....
.... ....
.... ....
[ 6.241182] cfg80211: Calling CRDA to update world regulatory domain
[ 6.375266] rtl8188ee 0000:01:00.0: enabling device (0000 -> 0003)
[ 6.383289] rtl8188ee: Using firmware rtlwifi/rtl8188efw.bin
[ 6.397905] ieee80211 phy0: Selected rate control algorithm 'rtl_rc'
[ 6.398161] rtlwifi: wireless switch is on
.... ....

connman-gnomeを起動してみると、Serviesリストにちゃんと[Wireless Networks]のエントリが追加されていました。
UBShot_20150113_123138-YoctoLinux-Enabling_RTL8188EE_WLAN_Driver-1366x768
Wi-Fiアクセスポイントへの接続を試してみると、こちらも問題なくできました。
UBShot_20150113_123405-YoctoLinux-Enabling_RTL8188EE_WLAN_Driver-1366x768

■ XS36V4用BSPの作成


上記のとおり、一時的にカーネルのコンフィグレーション設定を変更してRTL8188EEドライバを組み込めば、Yocto LinuxでXS36V4のWi-Fi機能を使えるようになることを確認できました。そこで、XS36V4用のBSPを作成して、この成果をそれに反映しました。

2014/10/25の記事にDE3815TYKHE用BSPの作成方法を書きましたが、これと同じ方法でXS36V4用のBSPを作成しました。今回作成したXS36V4 BSPのファイル構成を以下に示します。

  meta-xs36v4
|-- conf
| |-- machine
| | `-- xs36v4.conf
| `-- layer.conf
|-- recipes-bsp
| `-- formfactor
| |-- formfactor
| | `-- xs36v4
| | `-- machconfig
| `-- formfactor_0.0.bbappend
`-- recipes-kernel
`-- linux
`-- linux-yocto_3.10.bbappend

また、以下にXS36V4 BSPのレイヤ定義ファイル、ターゲット定義ファイル、カーネルレシピの内容を示します。
#We have a conf and classes directory, add to BBPATH
BBPATH .= ":${LAYERDIR}"

# We have a recipes directory, add to BBFILES
BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
${LAYERDIR}/recipes-*/*/*.bbappend"

BBFILE_COLLECTIONS += "xs36v4"
BBFILE_PATTERN_xs36v4 := "^${LAYERDIR}/"
BBFILE_PRIORITY_xs36v4 = "6"

LAYERDEPENDS_xs36v4 = "intel"

LICENSE_PATH += "${LAYERDIR}/custom-licenses"

#@TYPE: Machine
#@NAME: Shuttle XS36V4

#@WEBTITLE: Intel Celeron J1900 Processor (XS36V4) 64-bit with Open Source Frame Buffer Graphics

#@DESCRIPTION: Machine configuration for XS36V4 64-bit systems, without Intel-proprietary graphics bits

PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
PREFERRED_VERSION_linux-yocto ?= "3.10%"

require conf/machine/include/intel-corei7-64-common.inc
require conf/machine/include/intel-common-pkgarch.inc
require conf/machine/include/meta-intel.inc

MACHINE_FEATURES += "pcbios efi"
MACHINE_FEATURES += "wifi"

MACHINE_EXTRA_RRECOMMENDS += "linux-firmware"

XSERVER ?= "${XSERVER_X86_BASE} \
${XSERVER_X86_EXT} \
${XSERVER_X86_FBDEV} \
${XSERVER_X86_I965} \
"

APPEND += "acpi_enforce_resources=lax video=efifb:off vga=0x318"

FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"

#############################
# MACHINE = xs36v4 #
#############################
COMPATIBLE_MACHINE_xs36v4 = "xs36v4"
KMACHINE_xs36v4 = "valleyisland"
KBRANCH_xs36v4 = "standard/base"
KERNEL_FEATURES_xs36v4 = " features/valleyisland-io/valleyisland-io.scc \
features/valleyisland-io/valleyisland-io-pci.scc \
features/wifi/wifi-all.scc"

LINUX_VERSION_xs36v4 = "3.10.59"
SRCREV_machine_xs36v4 = "747e1cbd12b15db8bc2ae86e2359c1b113f120d6"
SRCREV_meta_xs36v4 = "8f05306a8e6f5ee422d50c3317acce0cf9e6aada"
SRCREV_valleyisland-io_xs36v4 = "0992d01f5f382f6da60004ef87f67ebd3ca13732"

SRC_URI_xs36v4 = "git://git.yoctoproject.org/linux-yocto-3.10.git;protocol=git;nocheckout=1;branch=${KBRANCH},${KMETA},valleyisland-io-3.0;name=machine,meta,valleyisland-io"

SRC_URI_xs36v4 += "file://add_driver-net_wlan_rtl8188ee.cfg"

module_autoload_i2c-dev = "i2c-dev"

上のファイルで定義しているのは64ビット版ターゲットだけです。今回32ビット版ターゲットの定義は省略しました。XS36V4で32ビット版Yocto Linuxを動かすことはまずないだろうと思ったからです。DE3815TYKHEでも、32ビット版ターゲット用にYocto Linuxをビルドしたことはいままで一度もありません。

上のカーネルレシピで使っているコンフィグレーションフラグメントは以下のような内容です。
++ .config	2015-01-12 15:55:39.777257022 +0900
CONFIG_RTL8188EE=m

このファイルは、カーネルのコンフィグレーション・メニュー画面でCONFIG_RTL8188EEの設定項目を有効にした直後に「bitbake linux-yocto -c diffconfig」コマンドを実行することで作成しました。

上記のXS36V4用BSPを作成した後、このBSPを使ってcore-image-satoイメージをビルドし、XS36V4でYocto Linuxが起動することを確認しました。Wi-Fi機能も問題なく動作しています。

なお、Shuttle XS36V4にはXS35V4という姉妹モデルが存在しますが、この2つの機種のハード仕様は同一だと思われます。未確認ですが、今回作成したBSPはXS35V4でも使えるはずです。〔本記事に掲載したXS36V4 BSPを利用してXS35V4で動作確認を行った方がいれば、その結果をコメントで報告していただけると有難いです〕

ページ前記事で紹介したとおり、Intel DE3815TYKHEというE3815搭載ベアボーンPCでYocto Linuxを動かしましたが、この作業はすんなりと終わりました。しかし、Yocto Linuxを動かすことには成功しましたが、一つ課題が見つかりました。それは、Yocto LinuxがDE3815TYKHE内蔵のEthernetデバイスを認識していないことです。

DE3815TYKHEでYocto Linuxを起動した後に、ターミナルからifconfigコマンドを実行すると、下のような出力が表示されました。
# ifconfig
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)


Ethernetデバイスが認識されていれば「eth0」というネットワーク・インターフェースが表示されるはずですが、それが存在していません。

DE3815TYKHEのハードウェア仕様について調べてみると、こいつに搭載されているEthernetデバイスはどうもRealtekのRTL8111Gのようです。 lspciコマンドによる情報でもそれが判ります。
# lspci
00:00.0 Host bridge: Intel Corporation ValleyView SSA-CUnit (rev 0c)
00:02.0 VGA compatible controller: Intel Corporation ValleyView Gen7 (rev 0c)
00:13.0 SATA controller: Intel Corporation ValleyView 6-Port SATA AHCI Controller (rev 0c)
00:14.0 USB controller: Intel Corporation ValleyView USB xHCI Host Controller (rev 0c)
00:1a.0 Encryption controller: Intel Corporation ValleyView SEC (rev 0c)
00:1b.0 Audio device: Intel Corporation ValleyView High Definition Audio Controller (rev 0c)
00:1c.0 PCI bridge: Intel Corporation ValleyView PCI Express Root Port (rev 0c)
00:1c.1 PCI bridge: Intel Corporation ValleyView PCI Express Root Port (rev 0c)
00:1c.2 PCI bridge: Intel Corporation ValleyView PCI Express Root Port (rev 0c)
00:1f.0 ISA bridge: Intel Corporation ValleyView Power Control Unit (rev 0c)
00:1f.3 SMBus: Intel Corporation ValleyView SMBus Controller (rev 0c)
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0c)

さらにググって調べると、Realtek RTL8111用ドライバはLinuxカーネルのソースツリーに存在しており、それをカーネルへ組み込むには、「CONFIG_R8169」という設定を有効にすれば良いらしいことが判りました。現状のE38xx用Yocto Linuxでこのコンフィグレーション設定が有効になっているか確認すると、やはり有効になっていませんでした。
# zcat /proc/config.gz | grep CONFIG_R8169
# CONFIG_R8169 is not set

上記の情報に基づいて、Yocto LinuxのE38xx BSPへRTL8111用ドライバを追加するカスタマイズを行ったので、その作業の詳細内容を掲載します。このカスタマイズ作業は特定のBSPに依存していません。したがって、Yocto LinuxのBSPをカスタマイズしたい場合の参考情報になると思います。

■ カーネル・カスタマイズのワークフロー


最初に、Yocto Linuxのカーネルをカスタマイズする方法について記します。カーネルのカスタマイズによって課題を解決できた後にその結果をBSPへ反映する流れで、2つのフェーズに分けて作業をします。なお、Yocto Projectの公式サイトに掲載されている以下のページの内容を参考にして以降の作業を行いました。

 Yocto Project Linux Kernel Development Manual

また、以降の内容は、09/24の記事のYocto Linuxのビルド作業が一度完了していることを仮定しています。

システム構成イメージまたはカーネルのビルドが完了している状態で、Yocto Linuxのカーネルのカスタマイズを始めたい場合は、次のコマンドを使います。
$ bitbake linux-yocto -c menuconfig

このコマンドを実行すると、カーネルの「make menuconfig」に相当する処理が起動され、カーネルのコンフィグレーション・メニュー画面が別ウィンドウで開きます。
UBShot_20141025_124348-Customizing_YoctoLinux1.6.1_E38xx_BSP_for_DE3815TYKE.png
ここで表示されているメニュー画面には、ビルド済みのターゲット用カーネルのコンフィグレーション設定が完全に反映されています。このメニュー画面から目的の設定項目を変更すれば、カーネルをカスタマイズすることができます。

今回の目的はRTL8111用ドライバをカーネルへ組み込むことなので、以下のとおりに、メニューを辿って該当する設定項目を有効にしました。
         Device Drivers  --->

[*] Nework device support --->

[*] Ethernet driver support --->

[*] Realtek devices
<M> Realtek 8169 gigabit ethernet support

UBShot_20141025_124750-Customizing_YoctoLinux1.6.1_E38xx_BSP_for_DE3815TYKE.png
上のメニュー項目名では「Realtek 8169」となっています。Realtekのサイトの情報によると、RTL8169/8110はPCIベースのEthernet Controllerですが、カーネルに組み込まれているドライバは最新版であり、このドライバはPCIeベースのRTL8168/8111にも対応しているらしいです。

コンフィグレーション・メニュー画面によるカーネル設定の変更がすべて終わったら、<Exit>を選びながら画面を遡っていき、最後の確認画面で<Yes>を選択すれば設定内容を保存できます。
UBShot_20141025_135805-Customizing_YoctoLinux1.6.1_E38xx_BSP_for_DE3815TYKE.png
変更したコンフィグレーション設定を適用してカーネルを再ビルドしたい場合は、次のコマンドを実行すれば、その処理が走ります。
$ bitbake linux-yocto -c compile -f

カーネルの再ビルドが終了したら、以下のコマンドを実行すれば、<BUILD_DIR>/tmp/deploy/images/${MACHINE}ディレクトリへカーネルイメージがデプロイ(配置)されます。
$ bitbake linux-yocto -c deploy

さらに、sysrootの更新とカーネル・パッケージの作成も行いたい場合は、以下のコマンドを実行します。
$ bitbake linux-yocto

そして、さらに続けて下のコマンドを実行すると、再ビルドしたカーネルイメージを組み込んだシステム構成イメージを生成することができます。
$ bitbake core-image-sato

これによって、新しいhddimgイメージファイルが生成されます。

再ビルドによって更新したcore-image-satoのhddimgファイルをUSBメディアに書き込み、それを使ってDE3815TYKHEでYocto Linuxを起動してみました。そして、カーネルの「CONFIG_R8169」設定が有効になっているか確認しました。
# zcat /proc/config.gz | grep CONFIG_R8169
CONFIG_R8169=m

dmesgコマンドで起動直後のカーネルログを表示すると、以下のとおり、RTL8168/8169/8110/8111用ドライバがロードされていることが確認できました。
# dmesg
.... ....
.... ....
.... ....
.... ....
[ 6.060784] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
[ 6.062982] r8169 0000:03:00.0: irq 107 for MSI/MSI-X
[ 6.063331] r8169 0000:03:00.0 eth0: RTL8168g/8111g at 0xffffc9000001e000, xx:xx:xx:xx:xx:xx, XID 0c000800 IRQ 107
[ 6.063340] r8169 0000:03:00.0 eth0: jumbo features [frames: 9200 bytes, tx checksumming: ko]
[ 6.837858] r8169 0000:03:00.0 eth0: unable to load firmware patch rtl_nic/rtl8168g-2.fw (-2)
[ 6.842495] r8169 0000:03:00.0 eth0: link down
[ 6.842511] r8169 0000:03:00.0 eth0: link down
[ 6.842564] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 8.901567] r8169 0000:03:00.0 eth0: link up
[ 8.901604] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 12.206428] r8169 0000:03:00.0 eth0: link down
[ 12.206447] r8169 0000:03:00.0 eth0: link down
[ 12.206554] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 12.256193] r8169 0000:03:00.0 eth0: link up
[ 12.256233] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

Ethernetのネットワーク・インターフェースもちゃんと認識されていました。
# ifconfig
eth0 Link encap:Ethernet HWaddr XX:XX:XX:XX:XX:XX
inet addr:192.168.223.9 Bcast:192.168.223.255 Mask:255.255.255.0
inet6 addr: fe80::xxxx:xxff:fexx:xxxx/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:18 errors:0 dropped:0 overruns:0 frame:0
TX packets:49 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:3902 (3.8 KiB) TX bytes:8543 (8.3 KiB)

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)



■ DE3815TYKHE用BSPレイヤの作成


上記の作業によって、カーネルへのRTL8111用ドライバの組み込みは一応終わりましたが、この作業の結果は、<BUILD_DIR>/tmp/workディレクトリの下に一時的なビルド状態として残っています。この状態で(ソースの展開を伴う)カーネルのクリーンビルドを行うと、一時的なビルド状態は破棄されてしまいます。カーネルに対する変更内容を永続的な設定情報として保存したい場合は、それをBSPへ反映する必要があります。

Yocto LinuxのBSPはレシピの集合体ですが、BSPにはカーネルのレシピが含まれています。カーネルのコンフィグレーション設定を変更したい場合は、カーネルレシピにその内容を記述しなければなりません。E38xx BSPのレシピはディレクトリmeta-intel/meta-isg/meta-valleyisland以下に格納されており、そのファイル構成は以下のようになっています。

  meta-valleyisland
|-- conf
| |-- machine
| | |-- valleyisland-32.conf
| | `-- valleyisland-64.conf
| `-- layer.conf
|-- recipes-bsp
| `-- formfactor
| |-- formfactor
| | |-- valleyisland-32
| | | `-- machconfig
| | `-- valleyisland-64
| | `-- machconfig
| `-- formfactor_0.0.bbappend
`-- recipes-kernel
`-- linux
`-- linux-yocto_3.10.bbappend

上のうち、conf/layer.confがレイヤの定義ファイルです。そして、recipes-kernel/linux/linux-yocto_3.10.bbappendがカーネルのレシピ・ファイルです。この2つのファイルの内容を以下に示します。
#We have a conf and classes directory, add to BBPATH
BBPATH .= ":${LAYERDIR}"

# We have a recipes directory, add to BBFILES
BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
${LAYERDIR}/recipes-*/*/*.bbappend"

BBFILE_COLLECTIONS += "valleyisland\"
BBFILE_PATTERN_valleyisland := "^${LAYERDIR}/"
BBFILE_PRIORITY_valleyisland = "6"

LAYERDEPENDS_valleyisland = "intel"

LICENSE_PATH += "${LAYERDIR}/custom-licenses"

FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"

#############################
# MACHINE = valleyisland-32 #
#############################
COMPATIBLE_MACHINE_valleyisland-32 = "valleyisland-32"
KMACHINE_valleyisland-32 = "valleyisland-32"
KBRANCH_valleyisland-32 = "standard/base"
KERNEL_FEATURES_valleyisland-32 = " features/valleyisland-io/valleyisland-io \
features/valleyisland-io/valleyisland-io-pci"

LINUX_VERSION_valleyisland-32 = "3.10.43"
SRCREV_machine_valleyisland-32 = "aa677a2d02677ec92d59a8c36d001cf2f5cf3260"
SRCREV_meta_valleyisland-32 = "199943142f7e0a283240246ee6c02f4376b315f0"
SRCREV_valleyisland-io_valleyisland-32 = "27bc40c174bb4ca160eafd6ccf3da9e774c9a8c7"

SRC_URI_valleyisland-32 = "git://git.yoctoproject.org/linux-yocto-3.10.git;protocol=git;nocheckout=1;branch=${KBRANCH},${KMETA},valleyisland-io-2.0;name=machine,meta,valleyisland-io"

#############################
# MACHINE = valleyisland-64 #
#############################
COMPATIBLE_MACHINE_valleyisland-64 = "valleyisland-64"
KMACHINE_valleyisland-64 = "valleyisland"
KBRANCH_valleyisland-64 = "standard/base"
KERNEL_FEATURES_valleyisland-64 = " features/valleyisland-io/valleyisland-io \
features/valleyisland-io/valleyisland-io-pci.scc"

LINUX_VERSION_valleyisland-64 = "3.10.43"
SRCREV_machine_valleyisland-64 = "aa677a2d02677ec92d59a8c36d001cf2f5cf3260"
SRCREV_meta_valleyisland-64 = "199943142f7e0a283240246ee6c02f4376b315f0"
SRCREV_valleyisland-io_valleyisland-64 = "27bc40c174bb4ca160eafd6ccf3da9e774c9a8c7"

SRC_URI_valleyisland-64 = "git://git.yoctoproject.org/linux-yocto-3.10.git;protocol=git;nocheckout=1;branch=${KBRANCH},${KMETA},valleyisland-io-2.0;name=machine,meta,valleyisland-io"

module_autoload_i2c-dev = "i2c-dev"

上のlinux-yocto_3.10.bbappendを直接編集してレシピを改造することもできますが、Yocto Linuxで新しいターゲット用のBSPを作成する場合は、既存のBSPとは独立した新規のレイヤを作成するのがセオリーです。このセオリーに従って、ここでDE3815TYKHEのBSPレイヤの格納先ディレクトリを作成しました。
$ cd ~/Yocto
$ cd poky-daisy-11.0.1
$ cp -r meta-intel/meta-isg/meta-valleyisland meta-ed3815tyke

E38xx用BSPの全ファイルをディレクトリ構成を維持したままコピーして、DE3815TYKHE用BSPのディレクリトを作成しています(Yocto Linuxのレイヤ・ディレクトリには「meta-」という接頭詞を付けるのがルールになっています)。さらに、ファイルとディレクトリの名前にBSPのターゲット名が含まれているものをすべてリネームしました(DE3815TYKHE用BSPのターゲット名として、本体貼付のラベルに記載されている「DE3815TYKE」の方を採用しました)。
$ cd meta-ed3815tyke
$ cd conf/machine
$ mv valleyisland-32 de3815tyke-32
$ mv valleyisland-64 de3815tyke-64
$ cd ../..
$ cd recipes-bsp/formfactor
$ mv valleyisland-32 de3815tyke-32
$ mv valleyisland-64 de3815tyke-64

ここまでの操作によって、DE3815TYKHE用BSPレイヤのファイル構成は以下のようになりました。

  meta-de3815tyke
|-- conf
| |-- machine
| | |-- de3815tyke-32.conf
| | `-- de3815tyke-64.conf
| `-- layer.conf
|-- recipes-bsp
| `-- formfactor
| |-- formfactor
| | |-- de3815tyke-32
| | | `-- machconfig
| | `-- de3815tyke-64
| | `-- machconfig
| `-- formfactor_0.0.bbappend
`-- recipes-kernel
`-- linux
`-- linux-yocto_3.10.bbappend

ファイルとディレクトリのリネームが終わった後、conf/layer.confを以下のように編集しました。
#We have a conf and classes directory, add to BBPATH
BBPATH .= ":${LAYERDIR}"

# We have a recipes directory, add to BBFILES
BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
${LAYERDIR}/recipes-*/*/*.bbappend"

BBFILE_COLLECTIONS += "de3815tyke"
BBFILE_PATTERN_de3815tyke := "^${LAYERDIR}/"
BBFILE_PRIORITY_de3815tyke = "6"

LAYERDEPENDS_de3815tyke = "intel"

LICENSE_PATH += "${LAYERDIR}/custom-licenses"

さらに、カーネルレシピであるrecipes-kernel/linux/linux-yocto_3.10.bbappendも以下のように編集しました。
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"

#############################
# MACHINE = de3815tyke-32 #
#############################
COMPATIBLE_MACHINE_de3815tyke-32 = "de3815tyke-32"
KMACHINE_de3815tyke-32 = " valleyisland-32"
KBRANCH_de3815tyke-32 = "standard/base"
KERNEL_FEATURES_de3815tyke-32 = " features/valleyisland-io/valleyisland-io \
features/valleyisland-io/valleyisland-io-pci"

LINUX_VERSION_de3815tyke-32 = "3.10.43"
SRCREV_machine_de3815tyke-32 = "aa677a2d02677ec92d59a8c36d001cf2f5cf3260"
SRCREV_meta_de3815tyke-32 = "199943142f7e0a283240246ee6c02f4376b315f0"
SRCREV_valleyisland-io_de3815tyke-32 = "27bc40c174bb4ca160eafd6ccf3da9e774c9a8c7"

SRC_URI_de3815tyke-32 = "git://git.yoctoproject.org/linux-yocto-3.10.git;protocol=git;nocheckout=1;branch=${KBRANCH},${KMETA},valleyisland-io-2.0;name=machine,meta,valleyisland-io"

#############################
# MACHINE = de3815tyke-64 #
#############################
COMPATIBLE_MACHINE_de3815tyke-64 = "de3815tyke-64"
KMACHINE_de3815tyke-64 = "valleyisland"
KBRANCH_de3815tyke-64 = "standard/base"
KERNEL_FEATURES_de3815tyke-64 = " features/valleyisland-io/valleyisland-io \
features/valleyisland-io/valleyisland-io-pci.scc"

LINUX_VERSION_de3815tyke-64 = "3.10.43"
SRCREV_machine_de3815tyke-64 = "aa677a2d02677ec92d59a8c36d001cf2f5cf3260"
SRCREV_meta_de3815tyke-64 = "199943142f7e0a283240246ee6c02f4376b315f0"
SRCREV_valleyisland-io_de3815tyke-64 = "27bc40c174bb4ca160eafd6ccf3da9e774c9a8c7"

SRC_URI_de3815tyke-64 = "git://git.yoctoproject.org/linux-yocto-3.10.git;protocol=git;nocheckout=1;branch=${KBRANCH},${KMETA},valleyisland-io-2.0;name=machine,meta,valleyisland-io"

module_autoload_i2c-dev = "i2c-dev"

以上でDE3815TYKHE用BSPレイヤの作成は終わりですが、ここまでの作業でやった内容をまとめます。
  1. 改造したい既存のBSPの全ファイルを、ディレクトリ構成を維持してコピーする。
  2. ファイルとディレクトリの名前にターゲット名が含まれていたら、それらをすべて新ターゲット名にリネームする。
  3. conf, bb, bbappendファイル内の変数名にターゲット名が含まれていたら、それらをすべて新ターゲット名にリネームする(ついでに、コメント内のターゲット名もリネームしておく)。

上記の作業によって、コピー元のBSPと完全に同一の内容でターゲット名だけが異なるBSPを作成したことになります。

■ defconfigによるBSPのカスタマイズ


DE3815TYKHE用のBSPレイヤが作成できたので、これのカーネルレシピに、CONFIG_R8169を有効にするコンフィグレーション設定を追加します。

上記で「bitbake linux-yocto -c menuconfig」コマンドによってカーネルの設定を変更する方法を紹介しましたが、コンフィグレーション・メニュー画面によって変更を加えたカーネルの全設定内容は.configというファイルに保存されています。bitbakeコマンドによるカーネルのビルド時に実行されるコンフィグレーション・フェーズにおいて、変更後の.configの内容が適用されるようにすれば目的を達成できます。ここからDE3815TYKHE BSPをカスタマイズしていきます。

まずは、「bitbake linux-yocto -c menuconfig」コマンドによってカーネルのコンフィグレーション設定の変更を行った後、その設定内容が保存されている.configをDE3815TYKHE用BSPレイヤの特定のディレクトリへコピーします。
$ mkdir ../meta-de3815tyke/recipes-kernel/linux/linux-yocto
$ cp tmp/work/corei7-64-intel-common-poky-linux/linux-yocto/3.10.43+gitAUTOINC+199943142f_aa677a2d02-r0/linux-corei7-64-intel-common-standard-build/.config ../meta-de3815tyke/recipes-kernel/linux/linux-yocto/defconfig

コピー時にファイル名をdefconfigにリネームしてください(後述の「bitbake linux-yocto -c diffconfig」コマンドを実行した後だと、コピー元の.configの内容はコンフィグレーション・メニュー画面で変更を加える前の旧設定値に書き戻されています。その場合は、もう一度「bitbake linux-yocto -c menuconfig」コマンドによって設定変更をやり直した上で、.configdefconfigへコピーしてください)。

defconfigの作成が終わったら、新しく作成したDE3815TYKHE BSPのカーネルレシピを以下のとおりに書き換えます。
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"

#############################
# MACHINE = de3815tyke-32 #
#############################
COMPATIBLE_MACHINE_de3815tyke-32 = "de3815tyke-32"
KMACHINE_de3815tyke-32 = " valleyisland-32"
KBRANCH_de3815tyke-32 = "standard/base"
KERNEL_FEATURES_de3815tyke-32 = " features/valleyisland-io/valleyisland-io \
features/valleyisland-io/valleyisland-io-pci"

LINUX_VERSION_de3815tyke-32 = "3.10.43"
SRCREV_machine_de3815tyke-32 = "aa677a2d02677ec92d59a8c36d001cf2f5cf3260"
SRCREV_meta_de3815tyke-32 = "199943142f7e0a283240246ee6c02f4376b315f0"
SRCREV_valleyisland-io_de3815tyke-32 = "27bc40c174bb4ca160eafd6ccf3da9e774c9a8c7"

SRC_URI_de3815tyke-32 = "git://git.yoctoproject.org/linux-yocto-3.10.git;protocol=git;nocheckout=1;branch=${KBRANCH},${KMETA},valleyisland-io-2.0;name=machine,meta,valleyisland-io"

SRC_URI_de3815tyke-32 += "file://defconfig"

#############################
# MACHINE = de3815tyke-64 #
#############################
COMPATIBLE_MACHINE_de3815tyke-64 = "de3815tyke-64"
KMACHINE_de3815tyke-64 = "valleyisland"
KBRANCH_de3815tyke-64 = "standard/base"
KERNEL_FEATURES_de3815tyke-64 = " features/valleyisland-io/valleyisland-io \
features/valleyisland-io/valleyisland-io-pci.scc"

LINUX_VERSION_de3815tyke-64 = "3.10.43"
SRCREV_machine_de3815tyke-64 = "aa677a2d02677ec92d59a8c36d001cf2f5cf3260"
SRCREV_meta_de3815tyke-64 = "199943142f7e0a283240246ee6c02f4376b315f0"
SRCREV_valleyisland-io_de3815tyke-64 = "27bc40c174bb4ca160eafd6ccf3da9e774c9a8c7"

SRC_URI_de3815tyke-64 = "git://git.yoctoproject.org/linux-yocto-3.10.git;protocol=git;nocheckout=1;branch=${KBRANCH},${KMETA},valleyisland-io-2.0;name=machine,meta,valleyisland-io"

SRC_URI_de3815tyke-64 += "file://defconfig"

module_autoload_i2c-dev = "i2c-dev"

上のカーネルレシピの先頭に存在する「FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"」という記述に注目してください。この設定記述がdefconfigファイルの格納先ディレクトリ・パスを表しています。「${THISDIR}」がこのレシピファイル自身が格納されているディレクトリパスに、「${PN}」がファイル名linux-yocto_3.10.bbappendのパッケージ名部分である「linux-yocto」に翻訳されます。

以上で、DE3815TYKHE BSPのカスタマイズは完了です。「えー。たったこれだけ」と思われるかもしれませんが、本当にこれで完成です。ここまでの操作によって、DE3815TYKHE用BSPレイヤのファイル構成は以下のようになっています。

  meta-de3815tyke
|-- conf
| |-- machine
| | |-- de3815tyke-32.conf
| | `-- de3815tyke-64.conf
| `-- layer.conf
|-- recipes-bsp
| `-- formfactor
| |-- formfactor
| | |-- de3815tyke-32
| | | `-- machconfig
| | `-- de3815tyke-64
| | `-- machconfig
| `-- formfactor_0.0.bbappend
`-- recipes-kernel
`-- linux
|-- linux-yocto
| `-- defconfig
`-- linux-yocto_3.10.bbappend

このカスタマイズ済みのBSPを使って、Yocto Linuxをビルドしてみましょう。以下の手順に従えば、DE3815TYKHE用にYocto Linuxをビルドできます。
  1. 新しいターミナルを開いて、DE3815TYKHE用のビルド作業ディレクトリを作成します。
    $ cd ~/Yocto
    $ cd poky-daisy-11.0.1
    $ source oe-init-build-env de3815tyke

  2. ディレクリトde3815tykeの下に作成される以下の2つのファイルを編集します。
    --- conf/bblayers.conf.000	2014-10-24 17:59:58.912820953 +0900
    +++ conf/bblayers.conf 2014-10-24 18:01:19.972135858 +0900
    @@ -9,6 +9,9 @@
    /home/yuhri/Yocto/poky-daisy-11.0.1/meta \
    /home/yuhri/Yocto/poky-daisy-11.0.1/meta-yocto \
    /home/yuhri/Yocto/poky-daisy-11.0.1/meta-yocto-bsp \
    + /home/yuhri/Yocto/poky-daisy-11.0.1/meta-intel \
    + /home/yuhri/Yocto/poky-daisy-11.0.1/meta-intel/meta-tlk \
    + /home/yuhri/Yocto/poky-daisy-11.0.1/meta-de3815tyke \
    "
    BBLAYERS_NON_REMOVABLE ?= " \
    /home/yuhri/Yocto/poky-daisy-11.0.1/meta \

    --- conf/local.conf.000	2014-10-24 17:59:58.904820607 +0900
    +++ conf/local.conf 2014-10-24 18:06:16.568385416 +0900
    @@ -17,18 +17,18 @@
    # These two options control how much parallelism BitBake should use. The first
    # option determines how many tasks bitbake should run in parallel:
    #
    -#BB_NUMBER_THREADS ?= "4"
    +BB_NUMBER_THREADS ?= "8"
    #
    # Default to setting automatically based on cpu count
    -BB_NUMBER_THREADS ?= "${@oe.utils.cpu_count()}"
    +#BB_NUMBER_THREADS ?= "${@oe.utils.cpu_count()}"
    #
    # The second option controls how many processes make should run in parallel when
    # running compile tasks:
    #
    -#PARALLEL_MAKE ?= "-j 4"
    +PARALLEL_MAKE ?= "-j 8"
    #
    # Default to setting automatically based on cpu count
    -PARALLEL_MAKE ?= "-j ${@oe.utils.cpu_count()}"
    +#PARALLEL_MAKE ?= "-j ${@oe.utils.cpu_count()}"
    #
    # For a quad-core machine, BB_NUMBER_THREADS = "4", PARALLEL_MAKE = "-j 4" would
    # be appropriate for example.
    @@ -55,7 +55,8 @@
    #MACHINE ?= "edgerouter"
    #
    # This sets the default machine to be qemux86 if no other machine is selected:
    -MACHINE ??= "qemux86"
    +MACHINE ?= "de3815tyke-64"
    +MACHINE ??= "valleyisland-64"

    #
    # Where to place downloads
    @@ -251,3 +252,8 @@
    # track the version of this file when it was generated. This can safely be ignored if
    # this doesn't mean anything to you.
    CONF_VERSION = "1"
    +
    +# The meta-valleyisland contains support for Intel HD Audio. However, HD Audio
    +# driver is dependent on gstreamer plugins and ffmpeg plugins to work properly.
    +# These gstreamer plugins require license flags in order to be included in the build.
    +LICENSE_FLAGS_WHITELIST = "commercial"

  3. ここまでの準備が終わったら、DE3815TYKHE用のターゲット・イメージをビルドすることができます。
    $ bitbake core-image-sato -c fetchall
    $ bitbake core-image-sato

    上のコマンドによって、tmp/deploy/images/de3815tyke-64/core-image-sato-de3815tyke-64.hddimgというイメージ・ファイルが生成されます。

■ cfgファイルによるBSPのカスタマイズ


上記ではdefconfigを使ってBSPをカスタマイズする方法について説明しましたが、もう一つ別の方法があるのでそれも紹介しましょう。コンフィグレーションフラグメントというものを使って、カーネル・ビルド時の.configへ変更を加える方法です。

まずは、旧BSPのビルド作業ディレクリトに戻りましょう。Valley Island用にYocto Linuxをビルドした際のターミナル画面が開いたままなら、そちらの画面を選択します。ターミナル画面を閉じてしまっていたら、新しいターミナル画面を開き、oe-init-build-envスクリプトによってValley Island用のビルド作業ディレクリトへ移動してください。
$ cd ~/Yocto
$ cd poky-daisy-11.0.1
$ source oe-init-build-env valleyisland

そして、カーネルのコンフィグレーション・メニュー画面で変更した設定内容の差分を取得します。「bitbake linux-yocto -c menuconfig」コマンドを実行した後に、以下のコマンドを実行するとそれができます。
$ bitbake linux-yocto -c diffconfig

このコマンドによって、<BUILD_DIR>/tmp/work/corei7-64-intel-common-poky-linux/linux-yocto/3.10.43+gitAUTOINC+199943142f_aa677a2d02-r0の中にfragment.cfgというファイルが作成されます(Yocto Linuxでは、個々のコンフィグレーション設定のことを「Configuration Fragment(コンフィグレーションフラグメント)」と呼びます)。このfragment.cfgの中にカーネルのコンフィグレーション設定の差分情報が格納されています。このファイルの内容を以下に示します。
++ .config	2014-10-24 11:18:48.549296777 +0900
CONFIG_FW_LOADER=m
CONFIG_FIRMWARE_IN_KERNEL=y
CONFIG_EXTRA_FIRMWARE=""
CONFIG_FW_LOADER_USER_HELPER=y
CONFIG_R8169=m
# CONFIG_SND_HDA_CODEC_CA0132_DSP is not set

bitbake linux-yocto -c menuconfig」コマンドによって変更を加えたカーネルの新旧のコンフィグレーション設定値はそれぞれ.config.config.oldというファイルに保存されますが、上のコマンドはこの2つのファイルを比較して差分を生成しているようです。なお、「bitbake linux-yocto -c diffconfig」コマンドを実行すると、.configの内容はコンフィグレーション・メニュー画面によって変更する前の.config.oldの内容に書き戻されてしまいます(このコマンドによって生成したfragment.cfgは、変更前のカーネル・コンフィグレーション設定に対して適用すべきものだからでしょう)。

fragment.cfgを作成できたら、それをDE3815TYKHEのBSPレイヤ・ディレクトリへコピーします。
$ cp -p tmp/work/corei7-64-intel-common-poky-linux/linux-yocto/3.10.43+gitAUTOINC+199943142f_aa677a2d02-r0/fragment.cfg ../meta-de3815tyke/recipes-kernel/linux/linux-yocto/add_driver-net_ethernet_r8169.cfg

そして、DE3815TYKHE BSPのカーネルレシピを以下のとおりに書き換えます。
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"

#############################
# MACHINE = de3815tyke-32 #
#############################
COMPATIBLE_MACHINE_de3815tyke-32 = "de3815tyke-32"
KMACHINE_de3815tyke-32 = " valleyisland-32"
KBRANCH_de3815tyke-32 = "standard/base"
KERNEL_FEATURES_de3815tyke-32 = " features/valleyisland-io/valleyisland-io \
features/valleyisland-io/valleyisland-io-pci"

LINUX_VERSION_de3815tyke-32 = "3.10.43"
SRCREV_machine_de3815tyke-32 = "aa677a2d02677ec92d59a8c36d001cf2f5cf3260"
SRCREV_meta_de3815tyke-32 = "199943142f7e0a283240246ee6c02f4376b315f0"
SRCREV_valleyisland-io_de3815tyke-32 = "27bc40c174bb4ca160eafd6ccf3da9e774c9a8c7"

SRC_URI_de3815tyke-32 = "git://git.yoctoproject.org/linux-yocto-3.10.git;protocol=git;nocheckout=1;branch=${KBRANCH},${KMETA},valleyisland-io-2.0;name=machine,meta,valleyisland-io"

SRC_URI_de3815tyke-32 += "file://add_driver-net_ethernet_r8169.cfg"

#############################
# MACHINE = de3815tyke-64 #
#############################
COMPATIBLE_MACHINE_de3815tyke-64 = "de3815tyke-64"
KMACHINE_de3815tyke-64 = "valleyisland"
KBRANCH_de3815tyke-64 = "standard/base"
KERNEL_FEATURES_de3815tyke-64 = " features/valleyisland-io/valleyisland-io \
features/valleyisland-io/valleyisland-io-pci.scc"

LINUX_VERSION_de3815tyke-64 = "3.10.43"
SRCREV_machine_de3815tyke-64 = "aa677a2d02677ec92d59a8c36d001cf2f5cf3260"
SRCREV_meta_de3815tyke-64 = "199943142f7e0a283240246ee6c02f4376b315f0"
SRCREV_valleyisland-io_de3815tyke-64 = "27bc40c174bb4ca160eafd6ccf3da9e774c9a8c7"

SRC_URI_de3815tyke-64 = "git://git.yoctoproject.org/linux-yocto-3.10.git;protocol=git;nocheckout=1;branch=${KBRANCH},${KMETA},valleyisland-io-2.0;name=machine,meta,valleyisland-io"

SRC_URI_de3815tyke-64 += "file://add_driver-net_ethernet_r8169.cfg"

module_autoload_i2c-dev = "i2c-dev"

これでコンフィグレーションフラグメント版のBSPは完成です。コンフィグレーションフラグメント版のDE3815TYKHE用BSPレイヤのファイル構成を以下に示します。

  meta-de3815tyke
|-- conf
| |-- machine
| | |-- de3815tyke-32.conf
| | `-- de3815tyke-64.conf
| `-- layer.conf
|-- recipes-bsp
| `-- formfactor
| |-- formfactor
| | |-- de3815tyke-32
| | | `-- machconfig
| | `-- de3815tyke-64
| | `-- machconfig
| `-- formfactor_0.0.bbappend
`-- recipes-kernel
`-- linux
|-- linux-yocto
| `-- add_driver-net_ethernet_r8169.cfg
`-- linux-yocto_3.10.bbappend

このBSPを使って、DE3815TYKE用にYocto Linuxをビルドしてみましょう。

まずは、新しいターミナル画面を開いて、すでに作成済みのDE3815TYKE用ビルド作業ディレクトリへ移動します(もしDE3815TYKE用ビルド時のターミナル画面が開いていたら、そちらを選択します)。
$ cd ~/Yocto
$ cd poky-daisy-11.01
$ source oe-init-build-env de3815tyke

その上で、以下のコマンドを実行すれば、DE3815TYKE用のcore-image-satoイメージを再生成できます。
$ bitbake linux-yocto -c cleansstate
$ bitbake linux-yocto
$ bitbake core-image-sato

最初の「bitbake linux-yocto -c cleansstate」というコマンドは、既存のカーネルのビルド状態をすべて破棄するためのものです。このコマンドを実行すると、<BUILD_DIR>/tmp/work/corei7-64-intel-common-poky-linux/linux-yocto以下に作成されるカーネル用のビルド作業ディレクトリだけでなく、<BUILD_DIR>/tmp/deploy/images/${MACHINE}内のカーネルイメージファイルも削除されます。既存のカーネルのビルド状態をクリーンした後、「bitbake linux-yocto」コマンドを実行すれば、上で改変したカーネルレシピが適用されてカーネルが再ビルドされます。

以上、defconfigとcfgファイルを使ってBSPをカスタマイズする方法を紹介しました。どちらの方法でカスタマイズしても、改造後のBSPからビルドされるYocto Linuxは同一です。目的に応じて、この2つの方法を使い分けてれば良いと思いますが、前者の方法ではカーネルレシピの変更は一度だけで済みます。defconfigにはカーネル・コンフィグレーションの全設定内容が格納されているからです。カーネルのコンフィグレーション設定をさらに変更したい場合でも、BSPレイヤ内のdefconfigだけを更新してやれば良い訳です。これに対して、後者では、カーネルのコンフィグレーション設定を追加変更したい場合、毎回cfgファイルを生成して、その内容がカーネルへ反映されるようにカーネルレシピも変更してやる必要があります。後者の方法は手間がかかるように思えますが、機能別にcfgファイルを作成することができるというメリットがあります。

Yocto Projectから公開・配布されている全ファイルは、下のGitリポジトリで管理されています。

 Yocto Project - Source Repositories

このサイトのファイルはWebブラウザで参照することもできます。本業の仕事とプライベートな活動の両方でYocto Projectの研究を始めて以来、毎日上記のサイトのたくさんのレシピファイルを眺めていますが、Yocto LinuxのBSPの多くはcfgファイルを利用した形式になっています。

【2014/11/27 追記】

Yocto Project Gitリポジトリのlinux-yocto-3.10ツリーをチェックしていたら、下のようなコミットが存在することに気づきました。
SCShot_141127_0007-YoctoProejct_Git-linux-yocto-3.10-8f05306a8e6f5ee422d50c3317acce0cf9e6aada-1145x967
このコミットにより、Valley Island BSPのカーネルへRealtek RTL8168/8169/8110/8111用ドライバを有効にするコンフィグレーション設定が追加されたようです。本コミットのコメントでは「valleyisland 32bit」となっていますが、「valleyisland 64bit」の方にも同じ変更が加えられていることを確認しました。以下が、その内容です。
kconf hardware valleyisland.cfg

include cfg/x86_64.scc
include cfg/efi.scc
include cfg/dmaengine.scc
include cfg/8250.scc

include features/power/intel.scc

include features/i2c/i2c.scc
include features/i2c/i2cdev.scc

include features/i915/i915.scc

include features/intel-e1xxxx/intel-e100.scc
include features/intel-e1xxxx/intel-e1xxxx.scc

include features/spi/spi.scc
include features/spi/spidev.scc

include features/usb/ehci-hcd.scc
include features/usb/xhci-hcd.scc

kconf hardware bsp/common-pc/common-pc-eth.cfg

# Common Ethernet networking devices (including QEMU and Common PCs)
# Set very common NICs to y to avoid common NFS booting failures and the
# resulting bug reports.
CONFIG_NET_CORE=y
CONFIG_ETHERNET=y
CONFIG_MII=y
CONFIG_NET_VENDOR_BROADCOM=y
CONFIG_TIGON3=y
CONFIG_NET_VENDOR_ATHEROS=y
CONFIG_ATL2=m
CONFIG_NET_VENDOR_INTEL=y
CONFIG_E1000=y
CONFIG_NET_VENDOR_AMD=y
CONFIG_PCNET32=y
CONFIG_NET_VENDOR_REALTEK=y
CONFIG_8139CP=m
CONFIG_8139TOO=m
CONFIG_R8169=m
CONFIG_NET_VENDOR_ATHEROS=y
CONFIG_ATL1E=m

試しに、Yocto ProjectのGitリポジトリからPoky(Yocto Core)とValley Island BSPの最新版を取得して、この2つを組み合わせて、valleyisland-64ターゲット用のcore-image-satoイメージをビルドしてみました。さらに、生成したcore-image-sato-valleyisland-64.hddimgをUSBメディアへ書き込んで、そのメデイアを使ってDE3815TYKHEでYocto Linuxを起動してみました。その結果、カーネルのブート時にRTL8111ドライバがロードされて、eth0インターフェースがちゃんと作成されていることが確認できました。なお、PokyとValley Island BSPの公式リリース版はいずれもDaisy 1.6.1からDizzy 1.7へバージョンアップされていますが、後者には上記の変更内容が収納されているようです。

Yocto Projectの公式サイトやGitリポジトリからValley Island(Intel E38xx)BSPのDizzy 1.7以降(最新版を含む)を取得して、そのBSPからYocto Linuxのビルドを行う場合は、すでにカーネルにRTL8111(r8169)ドライバが組み込まれているので、本記事に記載した作業を行う必要はありません(もしかして、本記事の内容が上記のコミットのきっかけになったんでしょうか。もしそうなら嬉しいんですが・・・。Yocto Projectの開発者メンバーは日本語の記事なんかチェックしていないでしょうから、その可能性はないでしょうね)。

ちなみに、J1800/1900やE38xxプロセッサを搭載したボードは大抵Intel I210かRealtek RTL8111のどちらかのEthernetコントローラが実装されています。

【2014/12/27 追記】

Yocto Projectの公式サイトで、Poky(Yocto Project Core)のDaiay 1.6.2がリリースされています。下がそのリリース情報ページです。

 YP Core - Daisy 1.6.2 | Yocto Project

公式サイトも毎日チェックしているので、上のリリースの存在は知っていたのですが、昨日公式サイトのダウンロード・ページをチェックしていたら、Valley Island (Intel E38xx)BSPのDaisy 1.6.2リリース版がアップされているのを見つけました。公式サイト上にまだリンクは存在していないようですが、下がこのリリース版ファイルのリンクです。

 http://downloads.yoctoproject.org/releases/yocto/yocto-1.6.2/machines/valleyisland/valleyisland-1.0-daisy-1.6.2.tar.bz2

私がいままで使っていたPokyとValley Island はいずれもDaisy 1.6.1リリースのものです。じつは、(いままでのリリースも含めて)このValley Island (Intel E38xx)BSPの配布パッケージにはcore-sato-imageのhddimgファイルが収納されています。core-sato-imageイメージのビルドは最低でも2時間以上かかるので、手っ取り早くターゲットでYocto Linuxの動作確認をやりたい場合は、このファイルを利用すると良いです。

上のValley Island BSP Daisy 1.6.2に収納されているcore-sato-image-valleyisland-64.hddimgからLive USBメディアを作成し、それを使ってDE3815TYKHEでYocto Linuxを起動してみました。そして、ifconfigコマンドを実行すると、何とeth0インターフェースが生成されていました。dmesgコマンドの情報でも、r8169ドライバがロードされていることが確認できました。このBSPには、上の追記で紹介したGitコミットの更新内容が適用されているようです。
posted by とみやん at 10:28| Comment(0) | TrackBack(0) | Embedded Linux > Yocto Project

2014年10月13日

[Yocto] Intel DE3815TYKHEでYocto Linuxを動かす

Yocto Projectの研究に取り組みを始めて以来、最近はYocto Linuxの研究活動ばかりやっています。本業の仕事でもYocto Linuxの研究開発をやっているので、休日の時間までYocto Linuxをいじくり回すのに使ったりしています。Intel E38xxシリーズが組み込み向けに有望なプロセッサであることを知って以来、プライベートな研究活動用のターゲットとして同プロセッサを搭載したハードを探していましたが、やっとIntel NUC DE3815TYKHE(本体貼付のラベルでは、製品名は「DE3815TYKE」と記載されています)というベアボーンキットを入手できました。この機種に搭載されているプロセッサはIntel E3815です。
ANShot_20141012_113551-DE3815TYKHE-PackageItems.jpg
ANShot_20141012_113831-DE3815TYKHE-BackView.jpg
ANShot_20141013_134008-DE3815TYKHE-LabelOnBack.jpg
ANShot_20141012_130601-DE3815TYKHE-StandView.jpg
サイズは小さめの弁当箱くらいです。こういう小型のベアボーンキットは結構前から出回っていて、秋葉原のPCショップなどで見かけることもありました。デストップPC用のベアボーンキットはメジャー・メーカー製の物が多いですが、小型のベアボーンキットは大抵はマイナーなメーカーの製品でした。ところが、ここ数年省電力PCやホームサーバーの需要が高くなっているため、ASUSやGIGABYTEなどのメジャーなメーカーもこの種の製品を多く販売するようになっています。最近ではIntel自らこういう製品を販売していて(Intelが製造している訳ではなく、台湾か中国メーカーのOEM品でしょうが)、小型省電力ベアボーンPCの統一的な製品呼称としてIntelは「NUC(Next Unit of Computing)」という名称を使っています。今回私が購入したDE3815TYKHEという製品もIntel NUCシリーズ・ベアボーンキットの一つです。

じつは、MinnowBoard MAXのE3825 Daul-core版が欲しくて、こいつを個人輸入するべきかずいぶん悩みました。このボードはまだ予約注文しか受けつけていない状況のようで、MOUSERの商品ページでは「在庫:0 工場リードタイム:20週間」(本記事投稿時点)になっています。いま注文しても、実際に入手できるのは3〜4ヶ月位(もしかするともっと先)になるんじゃないかと思えました。これ以外にE38xx搭載ボードが他にないかと探し廻ったのですが、現状日本国内ですぐに入手できるのはDE3815TYKHEくらいしか見つかりませんでした。J1800/J1900 Bay Trail-Dを搭載したMini-ITXボードならASUS, GIGABYTE, ASRockなどから多くの種類の製品が販売されており、秋葉原のPCショップやAmazonでも購入できます。しかし、Bay Trailシリーズの最新版かつ最省電力版プロセッサであるE3800シリーズを搭載したボードは産業用として売られているものが多く、まだ製品の種類も製造量も少ないのが実情です。「E3845 Mini-ITX」というキーワードでググってみると、以下のようなページくらいしか見つかりませんでした。
 
  1. EMB-BT1 - Industrial Motherboards - Mini-ITX Motherboards
  2. WADE-8078,Mini-ITX,Embedded System Board,Embedded Computer- Portwell, Inc.
  3. COMMELL LV-67O Mini-ITX Support Bay Trail Intel Celeron J1900/N2930 and Atom E3845 Processor
  4. DFI Low-Power Mini-ITX Motherboards Support Intel Atom Processor-based SoC
  5. ASRock > UTX-110
  6. ASRock > ASRock UTX-110: スリム、スマート、そしてパワフル!

上のうち、1〜2は産業用ボード製品のようです。価格も高そうなので、入手は諦めた方が良さそうです。COMMELLとDFIのボードも産業用かもしれませんが、この2つのメーカーはデスクトップやサーバー用PCのマザーボードも製造しています(COMMELLは産業用ボードが主力製品です)。しかし、どちらもマイナーなメーカーなので、これらのボードも日本国内で入手するのは難しいでしょう。最後の2つのリンクは、ASRock製のUTXフォームファクタのボードの製品ページです。このボードも産業用みたいで、まだ発売されて間もない製品のようです。じつは、上のボードの中で一番欲しいと思ったのがこれです。ASRockはメジャーなメーカーなので、もしかすると日本へもこの製品が入ってくる可能性があるかもしれません。もしそうならったら、ぜひこいつを購入してみたいです。MinnowBoard MAXのようにフォームファクタがMini-ITXでないボードもありますが、ケーブルやケースなどの入手性を考えると、やはりMini-ITXがベストの選択でしょう。当面は今回入手したDE3815TYKHEを使っていきますが、近いうちにE3845(4コアのBay Trail-I)を搭載したMini-ITXボードを必ず入手しようと思っています。

■ DE3815TYKHEの組み立て


DE3815TYKHEに部品を追加して組み上げたので、その作業の様子を紹介します。DE3815TYKHEはベアボーンキットですが、CPUのE3815はオンボードの直付けです。したがって、追加部品として必要なのはメモリとSATAディスクだけです。以下の2つの部品を用意しました。
  • SAMSUNG純正PC3-12800 SO-DIMM 2GB DDR3L(電圧1.35V)対応モデル
  • Intel 320 Series SSD 80GB

前者はDE3815TYKHEと一緒にAmazonから購入し、後者はオークションで中古品を落札しました。メモリは2GBと4GBのどちらにするかずいぶん悩みました。Windows 7/8/8.1ならメモリは最低4GB搭載しないと実用になりませんが、こいつにWindowsを入れるつもりはまったくありません。Linuxの場合も実用機として使うならメモリは4GBあった方がベターですが、このDE3815TYKHEは開発専用ターゲットとしてしか使わないつもりなので2GBで十分だと思いました。

まずはDE3815TYKHEのカバーを開いてみました。下がDE3815TYKHEの内部の写真です。
ANShot_20141012_121052-DE3815TYKHE-BuildingUp.jpg
左側の一番大きなコネクタがDIMMスロットで、右側のスペースがディスクドライブを取り付け場所のようです。ちなみに、真ん中に位置するコネクタはMini-PCIeのスロットのようで、アンテナケーブルらしき物も見受けられます。ディスクドライブ用の金具を取り外して確認すると、このケーブルの先にちゃんとアンテナが付いていて、アンテナ本体部分はケース内側に貼り付けられていました。ということは、無線LANモジュールを取り付けるだけでWi-Fi機能を追加できることになります。そのうち、適当な無線LANモジュールを入手して、このMini-PCIeスロットに取り付けようと思っています。

いずれの部品も取り付け作業は特に難しくありません。部品用のネジもすべて付属しています。メモリはDIMMスロットへ挿し込むだけです。ディスクドライブの方は、金具を外して、それにディスクをネジ止めしてから、元の場所に戻すだけです。
ANShot_20141012_121831-DE3815TYKHE-BuildingUp.jpg
ANShot_20141012_122023-DE3815TYKHE-BuildingUp.jpg
ANShot_20141012_122800-DE3815TYKHE-BuildingUp.jpg
ANShot_20141012_122857-DE3815TYKHE-BuildingUp.jpg
ANShot_20141012_123402-DE3815TYKHE-BuildingUp.jpg
下の写真が、DE3815TYKHEにメモリとSSDを取り付けた状態です。
ANShot_20141012_124338-DE3815TYKHE-BuildingUp.jpg
PCを組み立てたことのある人なら誰でもできるでしょうし、そういう経験を持ってない人でもできそうなほど簡単な作業でした。メモリとSSDを取り付けたら、カバーを閉めれば組み立ては終わりです。

組み立て作業が終わったので、さっそくDE3815TYKHEの電源を入れてみました。すると、下のようなIntel NUCのロゴ画面がモニタに表示されました。
ANShot_20141012_151426-DE3815TYKHE-BIOS_Screen.jpg
この画面が表示された直後に、キーボードの[F2]キーを押すと、BIOSの画面が表示されました。
ANShot_20141012_134629-DE3815TYKHE-BIOS_Screen.jpg
PCやマザーボードのBIOS画面は大抵はキャラクタ・ベースのものが多いのですが、DE3815TYKHEのBIOS画面はグラフィカルなものでなかなか凝っています。このBIOS画面にはポインタ(矢印)が表示されているので、一見マウスが必要なように思えますが、キーボードだけでも操作できます。[Tab]キーを押す度に、画面上の選択可能なボタンやタブへ順次カーソル(オレンジ色の枠線)が移動するので、目的の場所で[Space]キーを押せば、それを選択できるようになっています。DE3815TYKHEのBIOSの構成画面を以下に示します。
ANShot_20141012_135636-DE3815TYKHE-BIOS_Screen.jpg
ANShot_20141012_135750-DE3815TYKHE-BIOS_Screen.jpg
ANShot_20141012_140010-DE3815TYKHE-BIOS_Screen.jpg
ANShot_20141012_140053-DE3815TYKHE-BIOS_Screen.jpg
ANShot_20141012_140153-DE3815TYKHE-BIOS_Screen.jpg
ANShot_20141012_140220-DE3815TYKHE-BIOS_Screen.jpg
ANShot_20141012_140256-DE3815TYKHE-BIOS_Screen.jpg
最近のPCやマザーボードに搭載されているBIOSはほとんどUEFI(Unified Extensible Firmware Interface)ベースのものばかりです。予想していたとおり、やはりDE3815TYKHEのBIOSもUEFIベースでした。UEFIベースのBIOSでLinuxを動かす場合、色々なTipsがあります。この辺の情報もそのうち書こうと思っています。

一般のユーザーなら、こういうベアポーンPCへインストールするのはWindowsだと思いますが、私の場合はあくまで組込みターゲットとして使うことが目的なので、Windowsを入れることは将来もないでしょう。Bay Trailについて調べているうちに、DE3815TYKHEのような小型の省電力ベアボーンキットが数多く販売されていることを知ったので、近いうちにこういうベアボーンキットを使ってメディアサーバーを一台を組んでみたいと思っていますが、この計画を実行するときは、WindowsではなくLinuxでサーバー環境を構築するつもりです。最近はオープンソースソフトも充実してきているので、デスクトップとサーバーのいずれもLinuxで十分に実用的な環境を構築できるはずです。Windowsの方が楽かもしれませんが、Linuxを使った方がより深い知識が得られます。私にとってWindowsはすでに過去のOSなので、使うのは仕事上どうしても必要な場合だけです。

■ DE3815TYKHEによるYocto Linuxの動作確認


DE3815TYKHEを入手した最大の目的がYocto Linuxを動かすことだったので、さっそくそれに挑戦してみました。Intel E38xx用BSPのビルドは前記事の作業で終わっているので、ビルドによって生成したYocto Linuxのイメージから起動用メディアを作成するところから始めました。

Intelのサイトから入手できる参考ドキュメント「Building Intel(R) Atom(TM) Processor E3800 Development Kit Yocto Project Board Support Package (BSP): User Guide 」には、開発ホスト機へUSBメモリを挿した状態で以下のコマンドを実行すれば、Yocto Linuxの起動メディアを作成できると記載されています。
# Identify the device file for your USB thumb drive.
$ df
# To write the bootable image to USB thumb drive, we assume it is at /dev/sdc.
# Unmount the the USB thumb drive first.
$ umount /dev/sdc

# Go to the scripts directory in poky.
$ cd ~/development/poky/scripts/contrib/
# Command: ./mkefidisk.sh <USB> <path/to/image> <target/rootfs>

上の手順を私の環境に合わせて読み換えて、以下ようなコマンドを実行しました。
$ cd ~/Yocto/poky-daisy-11.0.1
$ source oe-init-build-env valleyisland

### Shell environment set up for builds. ###

You can now run 'bitbake <target>'

Common targets are:
core-image-minimal
core-image-sato
meta-toolchain
adt-installer
meta-ide-support

You can also run generated qemu images with a command like 'runqemu qemux86'
$ df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda1 97019612 5535000 86556308 7% /
udev 2053336 4 2053332 1% /dev
tmpfs 412128 828 411300 1% /run
none 5120 0 5120 0% /run/lock
none 2060640 152 2060488 1% /run/shm
/dev/sdb1 264223716 143770272 107031684 58% /mnt/vmdk1
.host:/ 499268000 283111972 216156028 57% /mnt/hgfs
/dev/sdc1 15729584 8 15729576 1% /media/3809-5052
$ umount /dev/sdc1
$ cd ../scripts/contrib
$ sudo ./mkefidisk.sh /dev/sdc ../../valleyisland/tmp/deploy/images/valleyisland-64/core-image-sato-valleyisland-64.hddimg /dev/sda
Image details
=============
image: `../../valleyisland/tmp/deploy/images/valleyisland-64/core-image-sato-valleyisland-64.hddimg' -> `core-image-sato-valleyisland-64-20140924035205.hddimg'
size: 259637248 bytes
modified: 2014-09-24 16:11:08.177183633 +0900
type: x86 boot sector, code offset 0x58, OEM-ID "SYSLINUX", sectors/cluster 8, root entries 512, Media descriptor 0xf8, sectors/FAT 248, heads 64, sectors 507104 (volumes > 32 MB) , serial number 0x54226e8b, label: "boot ", FAT (16 bit)

Device details
==============
device: /dev/sdc
vendor: BUFFALO
model: USB Flash Disk
size: 15453913088 bytes

Prepare EFI image on /dev/sdc [y/N]? y
Information: You may need to update /etc/fstab.

*****************
Boot partition size: 20 MB (/dev/sdc1)
ROOTFS partition size: 14662 MB (/dev/sdc2)
Swap partition size: 772 MB (/dev/sdc3)
*****************
Deleting partition table on /dev/sdc ...
2+0 records in
2+0 records out
1024 bytes (1.0 kB) copied, 7.3805e-05 s, 13.9 MB/s
Creating new partition table (MSDOS) on /dev/sdc ...
Information: You may need to update /etc/fstab.

Creating boot partition on /dev/sdc1
Information: You may need to update /etc/fstab.

Enabling boot flag on /dev/sdc1
Information: You may need to update /etc/fstab.

Creating ROOTFS partition on /dev/sdc2
Information: You may need to update /etc/fstab.

Creating swap partition on /dev/sdc3
Information: You may need to update /etc/fstab.

Model: BUFFALO USB Flash Disk (scsi)
Disk /dev/sdc: 15.5GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number Start End Size Type File system Flags
1 1049kB 19.9MB 18.9MB primary boot
2 19.9MB 14.7GB 14.7GB primary
3 14.7GB 15.5GB 772MB primary


Formatting /dev/sdc1 as vfat...
mkfs.vfat 3.0.12 (29 Oct 2011)
Formatting /dev/sdc2 as ext3...
mke2fs 1.42 (29-Nov-2011)
Filesystem label=root
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
895840 inodes, 3579648 blocks
178982 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=3665821696
110 block groups
32768 blocks per group, 32768 fragments per group
8144 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208

Allocating group tables: done
Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done

Formatting swap partition...(/dev/sdc3)
Setting up swapspace version 1, size = 753660 KiB
no label, UUID=311c78ce-c4e0-418f-9f56-9aa3d80575f1

Mounting images and device in preparation for installation...
Copying ROOTFS files...
Preparing boot partition...
Installation complete.

mkefdisk.shスクリプトの「Copying ROOTFS files…」というメッセージ出力の処理が実行されている途中で下のような警告ウィンドウが表示されましたが、USBメディアの作成は成功しているようです。
UBShot_20141012_150324-DE3815TYKHE-Running_YoctoLinux.png
ちなみに、起動メディアとして用意したのは16GBのUSBメモリ(USB 3.0対応の物)です。

上のコマンドによって作成したUSBメモリをDE3815TYKHEの前面のUSB 3.0対応ポートに挿した状態で、同機の電源を投入してみました。すると、モニタに下のようなGRUBのメニュー画面が表示されました。
ANShot_20141012_143831-DE3815TYKHE-Running_YoctoLinux.jpg
「おー。ブートできそうかなぁ?」と思いながら、この画面から「boot」という項目を選択してみましたが、下のようなエラーが表示されて、カーネルのブートシーケンスは途中で停止してしまいました。
ANShot_20141012_143917-DE3815TYKHE-Running_YoctoLinux.jpg
この現象の原因は良く判りませんが、もしかするとmkefdisk.shスクリプトによって作成したUSBメディアが対応しているのは、E38xx BSPの正規ターゲットであるIntel製の3種類のボードだけなのかもしれません。

上記の方法で作成したUSBメディアによってYocto Linuxを起動できなかったので、ここで色々な試行錯誤をしました。その結果、mkefdisk.shスクリプトに代わって下のようなコマンドを使えば、DE3815TYKHE用のUSB起動メディアを作成できることが判りました(DE3815TYKHEだけでなく他のメーカーのE38xx搭載ボードでも、下記の方法によって、Yocto LinuxのUSB起動メディアを作成できるんじゃないかと思います)。
$ cd ../../valleyisland
$ umount /dev/sdc1
$ sudo dd if=/dev/zero of=/dev/sdc bs=1M count=512
512+0 records in
512+0 records out
536870912 bytes (537 MB) copied, 41.7172 s, 12.9 MB/s
$ sync
$ sudo dd if=tmp/deploy/images/valleyisland-64/core-image-sato-valleyisland-64.hddimg of=/dev/sdc
507104+0 records in
507104+0 records out
259637248 bytes (260 MB) copied, 89.28 s, 2.9 MB/s
$ sync

最初にumountコマンドでUSBメモリをアンマウントしています。続いて、ddコマンドでUSBメモリの内容を消去し、さらにddコマンドにYocto Linuxのhddimgイメージ・ファイルを指定して、その格納イメージをUSBメモリへ書き込んでいます。このhddimgファイルには、ddコマンドに直接渡すことができるディスクバイナリ・イメージが格納されているようです。

上の手順によって作成したUSBメモリを挿した状態で、再度DE3815TYKHEの電源を投入してみました。すると、下のようなGRUBのメニュー画面がモニタに表示されました。
ANShot_20141012_154347-DE3815TYKHE-Running_YoctoLinux.jpg
この画面から「boot」を選択すると、今度はカーネルのブートシーケンスが正常に流れて、数秒後にYocto Projectのスプラッシュ画面が表示され、最後にSato Mobile Desktopの画面が表示されました。
ANShot_20141012_154838-DE3815TYKHE-Running_YoctoLinux.jpg
ANShot_20141012_155626-DE3815TYKHE-Running_YoctoLinux.jpg
USBメモリからYocto Linuxをブートできることが確認できたので、続いて、SATAディスクからブートできるか試してみました。USBメモリから起動した際にGRUBのメニュー画面に「install」という項目が存在しています。この「install」を選択することで、SATAディスクヘYocto Linuxのイメージを書き込むことができます。具体的な手順としては、GRUBのメニュー画面で「install」を選択します。
ANShot_20141012_155931-DE3815TYKHE-Running_YoctoLinux.jpg
すると、カーネルのブートシーケンスがしばらく流れた後、数秒後にディスクメディアの検索処理が自動的に実行されます。そして、USBメモリ以外のディスクメディアが見つかると、下のようなメッセージが表示されます。
ANShot_20141012_160429-DE3815TYKHE-Running_YoctoLinux.jpg
このメッセージに「y」と入力すれば、対象ディスク上にパーティションテーブルが作成され、さらにカーネルの起動イメージとrootfsファイル群の書き込みも自動的に実行されます。これらの処理が完了すると、下のようなメッセージが表示されてその状況が通知されます。
ANShot_20141012_160701-DE3815TYKHE-Running_YoctoLinux.jpg
上のメッセージの指示に従って、USBメモリを抜いてから[Enter]キーを押せば、PCがリブートして、SATAディスクからYocto Linuxが再起動します。下の写真が、DE3815TYKHEの内蔵SATAディスクから起動したSato Mobile Desktopが動いている様子です。
ANShot_20141012_161044-DE3815TYKHE-Running_YoctoLinux.jpg


posted by とみやん at 10:23| Comment(0) | TrackBack(0) | Embedded Linux > Yocto Project

2014年09月24日

[Yocto] Intel E38xx Bay Trail用BSPのビルド

新しい研究テーマとしてYocto Projectへの取り組みを始めました。本業の仕事で同じテーマの研究開発をやっているため必要に迫られて始めてしまったものですが、Yocto Projectが組込み分野において将来性の高いテーマであることが判ってきたことも大きな理由です。

Intel Z37xx Bay Trail-Tを搭載したタブレット製品はすでに日本国内でもたくさんの種類の製品が販売されていますが、E38xx Bay Trail-Iを搭載した製品はまだ数が少ないようです。しかし、海外ではすでに多くの種類の製品が登場しています。ARMも本来は省電力性能に優れたコアですが、SoCやSoM上に高性能なGPUを一緒に搭載するケースが増えるに伴い、ここ数年で消費電力が一気に高くなってきました。モバイル機器の場合搭載できるバッテリーの容量に限界があるため、プロセッサの省電力性能は製品設計上の大きな要件となります。ここにきてZ37xxやE38xxなどのBay Tralシリーズを搭載した製品が増えている理由は、これらのプロセッサの処理能力対省電力の性能バランスが非常に優れているからです。しかも、現状多くのARMブロセッサがまだ32ビット・コアなのに対してBay Trailは64ビット・コアです。これからBay Trailを搭載した製品がさらに増えていくでしょうし、タブレットなどのコンシューマ製品だけでなく組込み機器でも採用例が急増していくでしょう。x86アーキテクチャはARMより歴史が長いため、Linuxを代表とするオープンソース・ソフトウェア資産の量と質でも優位性があります。Intel社も組込み分野の取り組みを拡大しているので、Bay Trailとその動向を追いかけていくことは大きな可能性があると思っています。Intel Atom E38xxシリーズ製品のトップページと同プロセッサのデータシートのリンクを下に掲載しておきます。

 Intel(R) Atom(TM) Processor E3800 Product Family (Formerly Bay Trail)
 Intel(R) Atom(TM) Processor E3800: Datasheet

前記事では、Yocto LinuxをQEMU x86ターゲット用にビルドして動作確認を行うまでの手順について解説しました。QEMUは実機ターゲット無しで始められるので手っ取り早くて良いのですが、やはり実機ターゲットを使わないと組込み開発の醍醐味は味わえない気がします。そこで、Yocto Project研究着手の第二段階の作業として、Intel Atom E38xx Bay TrailターゲットでYocto Linuxを動かすことに挑戦します。Intel E38xx Bay Trailプロセッサを搭載したボードはまだ手に入れていないので、取りあえず、本記事にはBSPのビルド手順についてのみ記載します。E38xx用BSPはYocto Projectのサイトで配布されていますが、同BSPのビルド手順が記載されたドキュメントはIntel Embedded Design Centerから入手できます(同サイトの一部のドキュメントやソフトウェアは、ユーザー登録をしないと入手できせん)。それらのリンクを掲載しておきます。
  1. Yocto Project* Setup: Getting Start Guide
  2. Building Intel(R) Atom(TM) Processor E3800 Development Kit Yocto Project Board Support Package (BSP): User Guide

以降の作業は、上記のドキュメントを参照しながら進めていきました。また、Yocto LinuxのIntel E38xx BSPをビルドする過程で一つの問題に遭遇したので、それを解決した際のTips情報も記します。

■ Intel E38xx BSPビルド環境のセットアップ


まず最初に、Yocto Projectの公式サイトからIntel E38xxのBSPパッケージをダウンロードしました。そして、それをディレクトリpoky-daisy-11.0.1(Yocto LinuxのYP Core - Daisy 1.6.1リリースのパッケージファイルyocto-1.6.1/poky-daisy-11.0.1.tar.bz2を展開すると、作成されるディレクトリ)の中へ展開しました。
$ wget http://downloads.yoctoproject.org/releases/yocto/yocto-1.6.1/machines/valleyisland/valleyisland-1.0-daisy-1.6.1.tar.bz2
$ tar -jxvf valleyisland-1.0-daisy-1.6.1.tar.bz2 -C poky-daisy-11.0.1

このパッケージを展開すると、ディレクトリpoky-daisy-11.0.1の中にmeta-intelというディレクトリが作成されます。このディレクトリの中にIntel E38xx BSPのレシピが格納されています(Yocto Linuxでは、BSPもレシピの集合体です)。

ちなみに、このBSPは複数のIntel製E38xx搭載ボードに対応していますが、その中の一つが「Valley Island Development Kit」という旧称だったらしいです。Audio CodecやEthernet Controllerなどの外付けデバイスを除いて、市販のE38xx搭載ボードはIntel製ボードと同じ回路構成になっているものが多いようです。そのため、このBSPから生成したイメージは大抵のE38xxターゲットでそのまま動作します。

続いて、これからE38xxターゲット用にYocto Linuxのビルドを進めていくので、その作業ディレクトリを作成しました。
$ cd poky-daisy-11.0.1
$ source oe-init-build-env valleyisland

スクリプトoe-init-build-envを実行すると、パラメータで指定したディレクトリが作成され、自動的にそのディレクトリへ移動します。また、同ディレクトリの中に以下の3つのファイルが作成されます。
  • conf/bblayers.conf
  • conf/local.conf
  • conf/templateconf.cfg

参照ドキュメントBに記載されている手順に従って、ここで、conf/bblayers.confに以下のような変更を加えました。
--- bblayers.conf.orig	2014-09-24 10:37:56.647617629 +0900
+++ bblayers.conf 2014-09-24 11:51:08.512524758 +0900
@@ -9,6 +9,9 @@
/home/yuhri/Yocto/poky-daisy-11.0.1/meta \
/home/yuhri/Yocto/poky-daisy-11.0.1/meta-yocto \
/home/yuhri/Yocto/poky-daisy-11.0.1/meta-yocto-bsp \
+ /home/yuhri/Yocto/poky-daisy-11.0.1/meta-intel \
+ /home/yuhri/Yocto/poky-daisy-11.0.1/meta-intel/meta-isg/meta-valleyisland \
+ /home/yuhri/Yocto/poky-daisy-11.0.1/meta-intel/meta-tlk \
"
BBLAYERS_NON_REMOVABLE ?= " \
/home/yuhri/Yocto/poky-daisy-11.0.1/meta \

このbblayers.confというファイルには、レシピが格納されてる最上位ディレクトリ(これを「Layer(レイヤ)と呼びます」)の一覧が定義されています。bitbakeコマンドの実行時に、これらのディレクトリがレシピ検索の対象となります。上では、既存のレイヤにmeta-intelディレクトリに格納されている3つのレイヤを追加しています。これによって、E38xx BSPを構成する全レシピがbitbakeコマンドから参照できるようになります。

さらに、conf/local.confにも以下の変更を加えました。
--- local.conf.orig	2014-09-24 10:37:56.643617498 +0900
+++ local.conf 2014-09-24 10:50:20.594415847 +0900
@@ -17,18 +17,18 @@
# These two options control how much parallelism BitBake should use. The first
# option determines how many tasks bitbake should run in parallel:
#
-#BB_NUMBER_THREADS ?= "4"
+BB_NUMBER_THREADS ?= "8"
#
# Default to setting automatically based on cpu count
-BB_NUMBER_THREADS ?= "${@oe.utils.cpu_count()}"
+#BB_NUMBER_THREADS ?= "${@oe.utils.cpu_count()}"
#
# The second option controls how many processes make should run in parallel when
# running compile tasks:
#
-#PARALLEL_MAKE ?= "-j 4"
+PARALLEL_MAKE ?= "-j 8"
#
# Default to setting automatically based on cpu count
-PARALLEL_MAKE ?= "-j ${@oe.utils.cpu_count()}"
+#PARALLEL_MAKE ?= "-j ${@oe.utils.cpu_count()}"
#
# For a quad-core machine, BB_NUMBER_THREADS = "4", PARALLEL_MAKE = "-j 4" would
# be appropriate for example.
@@ -55,7 +55,7 @@
#MACHINE ?= "edgerouter"
#
# This sets the default machine to be qemux86 if no other machine is selected:
-MACHINE ??= "qemux86"
+MACHINE ??= "valleyisland-64"

#
# Where to place downloads
@@ -251,3 +251,8 @@
# track the version of this file when it was generated. This can safely be ignored if
# this doesn't mean anything to you.
CONF_VERSION = "1"
+
+# The meta-valleyisland contains support for Intel HD Audio. However, HD Audio
+# driver is dependent on gstreamer plugins and ffmpeg plugins to work properly.
+# These gstreamer plugins require license flags in order to be included in the build.
+LICENSE_FLAGS_WHITELIST = "commercial"

local.conf内に存在する「MACHINE ??= "valleyisland-64"」という設定項目がビルド対象ターゲットの定義です(local.confが作成された段階では、本項目は常に「qemux86」に設定されています)。Yocto LinuxのBSPには必ずターゲット定義ファイルというものが格納されています。E38xx BSPのターゲット定義ファイルは以下の2つです。
  • meta-intel/meta-isg/meta-valleyisland/conf/machine/valleyisland-32.conf
  • meta-intel/meta-isg/meta-valleyisland/conf/machine/valleyisland-64.conf

ファイル名から判るように、上記はそれぞれ32ビットと64ビット版Linuxのシステム構成です。これらのファイルの中から選択して、そのファイル名(「.conf」を除いた)を「MACHINE」に設定すると、bitbakeコマンドはターゲットを確定できるようになります。

また、local.conf内のBB_NUMBER_THREADS PARALLEL_MAKEの値をいずれも「8」に変更していますが、その理由は、開発ホストのUbunutを動かしているVMware仮想マシンのプロセッサコア数を4に変更したからです。

■ Intel E38xx BSPのビルド


Intel E38xx BSPのビルド環境が整ったので、ビルド対象イメージとしてcore-image-satoを指定して、その全ソースをダウンロードしました。
$ bitbake -c fetchall core-image-sato

しかし、下のようなエラーメッセージが出力されて、この処理は途中で停止してしまいました(エラー停止したのは、10分以上処理が進んだ後でした)。
ERROR: Fetcher failure: Fetch command failed with exit code 128, output:
fatal: repository '/home/ilab/linux-yocto/linux-yocto-3.10' does not exist

ERROR: Function failed: Fetcher failure for URL: 'git:///home/ilab/linux-yocto/linux-yocto-3.10;protocol=file;nocheckout=1;branch=standard/base,meta,valleyisland-io-2.0;name=machine,meta,valleyisland-io'. Unable to fetch URL from any source.
ERROR: Logfile of failure stored in: /home/yuhri/Yocto/poky-daisy-11.0.1/valleyisland/tmp/work/corei7-64-intel-common-poky-linux/linux-yocto/3.10.43+gitAUTOINC+cf4d9720de_aa677a2d02-r0/temp/log.do_fetch.13046
ERROR: Task 19 (/home/yuhri/Yocto/poky-daisy-11.0.1/meta/recipes-kernel/linux/linux-yocto_3.10.bb, do_fetch) failed with exit code '1'
NOTE: Tasks Summary: Attempted 628 tasks of which 0 didn't need to be rerun and 1 failed.
Waiting for 0 running tasks to finish:

Summary: 1 task failed:
/home/yuhri/Yocto/poky-daisy-11.0.1/meta/recipes-kernel/linux/linux-yocto_3.10.bb, do_fetch
Summary: There were 14 WARNING messages shown.
Summary: There were 2 ERROR messages shown, returning a non-zero exit code.

上のエラーメッセージの一部の文字列を指定してgrep検索すると、meta-intel/meta-isg/meta-valleyisland/recipes-kernel/linux/linux-yocto_3.10.bbappendというファイルがヒットしました。そこで、このファイルの内容を眺めていると、その中に以下のような記述の誤りが存在することに気づきました。
--- linux-yocto_3.10.bbappend.orig	2014-06-18 20:23:30.000000000 +0900
+++ linux-yocto_3.10.bbappend 2014-09-24 12:22:41.806418515 +0900
@@ -1,35 +1,35 @@
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"

#############################
# MACHINE = valleyisland-32 #
#############################
COMPATIBLE_MACHINE_valleyisland-32 = "valleyisland-32"
KMACHINE_valleyisland-32 = "valleyisland-32"
KBRANCH_valleyisland-32 = "standard/base"
KERNEL_FEATURES_valleyisland-32 = " features/valleyisland-io/valleyisland-io \
features/valleyisland-io/valleyisland-io-pci"

LINUX_VERSION_valleyisland-32 = "3.10.43"
SRCREV_machine_valleyisland-32 = "aa677a2d02677ec92d59a8c36d001cf2f5cf3260"
SRCREV_meta_valleyisland-32 = "199943142f7e0a283240246ee6c02f4376b315f0"
SRCREV_valleyisland-io_valleyisland-32 = "27bc40c174bb4ca160eafd6ccf3da9e774c9a8c7"

SRC_URI_valleyisland-32 = "git://git.yoctoproject.org/linux-yocto-3.10.git;protocol=git;nocheckout=1;branch=${KBRANCH},${KMETA},valleyisland-io-2.0;name=machine,meta,valleyisland-io"

#############################
# MACHINE = valleyisland-64 #
#############################
COMPATIBLE_MACHINE_valleyisland-64 = "valleyisland-64"
KMACHINE_valleyisland-64 = "valleyisland"
KBRANCH_valleyisland-64 = "standard/base"
KERNEL_FEATURES_valleyisland-64 = " features/valleyisland-io/valleyisland-io \
features/valleyisland-io/valleyisland-io-pci.scc"

LINUX_VERSION_valleyisland-64 = "3.10.43"
SRCREV_machine_valleyisland-64 = "aa677a2d02677ec92d59a8c36d001cf2f5cf3260"
-SRCREV_meta_valleyisland-64 = "cf4d9720de1c0f64402de70833dd6ccc12d04a3f"
+SRCREV_meta_valleyisland-64 = "199943142f7e0a283240246ee6c02f4376b315f0"
SRCREV_valleyisland-io_valleyisland-64 = "27bc40c174bb4ca160eafd6ccf3da9e774c9a8c7"

-SRC_URI_valleyisland-64 = "git:///home/ilab/linux-yocto/linux-yocto-3.10;protocol=file;nocheckout=1;branch=${KBRANCH},${KMETA},valleyisland-io-2.0;name=machine,meta,valleyisland-io"
+SRC_URI_valleyisland-64 = "git://git.yoctoproject.org/linux-yocto-3.10.git;protocol=git;nocheckout=1;branch=${KBRANCH},${KMETA},valleyisland-io-2.0;name=machine,meta,valleyisland-io"

module_autoload_i2c-dev = "i2c-dev"

SRCREV_meta_valleyisland-64SRC_URI_valleyisland-64はGit経由で取得するソースのリビジョンとURIの定義のようですが、オリジナルのlinux-yocto_3.10.bbappendでは、これらの値が前方に存在するSRCREV_meta_valleyisland-32SRC_URI_valleyisland-32と異なっています。32ビットと64ビット版BSPのソースは一括してGitリポジトリ上で管理されているはずなので、これらは同じ値でなければならないはずです。修正前のSRC_URI_valleyisland-64の設定値は、ローカルなディレクトリからソースを取得するための定義のように見えます(本BSPのメンテナーが開発中の暫定的な記述を残したまま、このファイルをGitリポジトリへCommitしてしまったのでしょう)。そのため、E38xx BSPの64ビット版ソースの一部を取得する処理で停止してしまったようです。

meta-intel/meta-isg/meta-valleyisland/recipes-kernel/linux/linux-yocto_3.10.bbappendに上の修正を加えた上で、再度「bitbake -c fetchall core-image-sato」コマンドを実行すると、ソースのダウンロード処理は最後まで通って正常に終了しました(全ソースをダウンロードするのに、エラー前後の時間を合計して25分かかりました)。

ソースのダウンロードが完了したので、core-image-satoイメージのビルドを実行しました。
$ time bitbake core-image-sato
Loading cache: 100% |###############################################################| ETA: 00:00:00
Loaded 1243 entries from dependency cache.
NOTE: Resolving any missing task queue dependencies

Build Configuration:
BB_VERSION = "1.22.0"
BUILD_SYS = "i686-linux"
NATIVELSBSTRING = "Ubuntu-12.04"
TARGET_SYS = "x86_64-poky-linux"
MACHINE = "valleyisland-64"
DISTRO = "poky"
DISTRO_VERSION = "1.6.1"
TUNE_FEATURES = "m64 corei7"
TARGET_FPU = ""
meta
meta-yocto
meta-yocto-bsp
meta-intel
meta-valleyisland
meta-tlk = "<unknown>:<unknown>"

NOTE: Preparing runqueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
WARNING: QA Issue: ELF binary '/home/yuhri/Yocto/poky-daisy-11.0.1/valleyisland/tmp/work/corei7-64-poky-linux/eglibc/2.19-r0/packages-split/nscd/usr/sbin/nscd' has relocations in .text
NOTE: validating kernel config, see log.do_kernel_configcheck for details
WARNING: QA Issue: ELF binary '/home/yuhri/Yocto/poky-daisy-11.0.1/valleyisland/tmp/work/corei7-64-poky-linux/quota/4.01-r1/packages-split/quota/usr/bin/quotasync' has relocations in .text
WARNING: QA Issue: ELF binary '/home/yuhri/Yocto/poky-daisy-11.0.1/valleyisland/tmp/work/corei7-64-poky-linux/quota/4.01-r1/packages-split/quota/usr/bin/quota' has relocations in .text
WARNING: QA Issue: ELF binary '/home/yuhri/Yocto/poky-daisy-11.0.1/valleyisland/tmp/work/corei7-64-poky-linux/quota/4.01-r1/packages-split/quota/usr/sbin/rpc.rquotad' has relocations in .text
WARNING: QA Issue: ELF binary '/home/yuhri/Yocto/poky-daisy-11.0.1/valleyisland/tmp/work/corei7-64-poky-linux/quota/4.01-r1/packages-split/quota/usr/sbin/quotaon' has relocations in .text
WARNING: QA Issue: ELF binary '/home/yuhri/Yocto/poky-daisy-11.0.1/valleyisland/tmp/work/corei7-64-poky-linux/quota/4.01-r1/packages-split/quota/usr/sbin/quot' has relocations in .text
WARNING: QA Issue: ELF binary '/home/yuhri/Yocto/poky-daisy-11.0.1/valleyisland/tmp/work/corei7-64-poky-linux/quota/4.01-r1/packages-split/quota/usr/sbin/setquota' has relocations in .text
WARNING: QA Issue: ELF binary '/home/yuhri/Yocto/poky-daisy-11.0.1/valleyisland/tmp/work/corei7-64-poky-linux/quota/4.01-r1/packages-split/quota/usr/sbin/convertquota' has relocations in .text
WARNING: QA Issue: ELF binary '/home/yuhri/Yocto/poky-daisy-11.0.1/valleyisland/tmp/work/corei7-64-poky-linux/quota/4.01-r1/packages-split/quota/usr/sbin/xqmstats' has relocations in .text
WARNING: QA Issue: ELF binary '/home/yuhri/Yocto/poky-daisy-11.0.1/valleyisland/tmp/work/corei7-64-poky-linux/quota/4.01-r1/packages-split/quota/usr/sbin/repquota' has relocations in .text
WARNING: QA Issue: ELF binary '/home/yuhri/Yocto/poky-daisy-11.0.1/valleyisland/tmp/work/corei7-64-poky-linux/quota/4.01-r1/packages-split/quota/usr/sbin/quotastats' has relocations in .text
WARNING: QA Issue: ELF binary '/home/yuhri/Yocto/poky-daisy-11.0.1/valleyisland/tmp/work/corei7-64-poky-linux/quota/4.01-r1/packages-split/quota/usr/sbin/quotacheck' has relocations in .text
WARNING: QA Issue: ELF binary '/home/yuhri/Yocto/poky-daisy-11.0.1/valleyisland/tmp/work/corei7-64-poky-linux/quota/4.01-r1/packages-split/quota/usr/sbin/edquota' has relocations in .text
WARNING: QA Issue: ELF binary '/home/yuhri/Yocto/poky-daisy-11.0.1/valleyisland/tmp/work/corei7-64-poky-linux/quota/4.01-r1/packages-split/quota/usr/sbin/warnquota' has relocations in .text
WARNING: The postinstall intercept hook 'update_pixbuf_cache' failed (exit code: 139)! See log for details!
WARNING: The postinstalls for the following packages will be postponed for first boot: gdk-pixbuf-loader-xpm gdk-pixbuf-loader-gif gdk-pixbuf-loader-jpeg gdk-pixbuf-loader-png
WARNING: The postinstall intercept hook 'update_font_cache' failed (exit code: 139)! See log for details!
WARNING: The postinstalls for the following packages will be postponed for first boot: liberation-fonts
NOTE: Tasks Summary: Attempted 4925 tasks of which 668 didn't need to be rerun and all succeeded.

Summary: There were 18 WARNING messages shown.

real 199m7.092s
user 556m26.375s
sys 121m47.961s

いくつかの警告メッセージが出力されましたが、ビルド処理は正常に終了しているようです(ビルドにかかった時間は3時間19分でした)。

下のとおり、ブートやrootfsのイメージはちゃんと生成されているようでした。
$ ls tmp/deploy/images/valleyisland-64
bootx64.efi
bzImage
bzImage--3.10.43+git0+199943142f_aa677a2d02-r0-valleyisland-64-20140924035205.bin
bzImage-valleyisland-64.bin
core-image-minimal-initramfs-valleyisland-64-20140924035205.rootfs.cpio.gz
core-image-minimal-initramfs-valleyisland-64-20140924035205.rootfs.manifest
core-image-minimal-initramfs-valleyisland-64.cpio.gz
core-image-minimal-initramfs-valleyisland-64.manifest
core-image-sato-valleyisland-64-20140924035205.hddimg
core-image-sato-valleyisland-64-20140924035205.iso
core-image-sato-valleyisland-64-20140924035205.rootfs.ext3
core-image-sato-valleyisland-64-20140924035205.rootfs.manifest
core-image-sato-valleyisland-64.ext3
core-image-sato-valleyisland-64.hddimg
core-image-sato-valleyisland-64.iso
core-image-sato-valleyisland-64.manifest
modules--3.10.43+git0+199943142f_aa677a2d02-r0-valleyisland-64-20140924035205.tgz
modules-valleyisland-64.tgz
README_-_DO_NOT_DELETE_FILES_IN_THIS_DIRECTORY.txt

E38xxを搭載したターゲットボードをまだ入手できていないので、ここまでで同プロセッサ搭載ターゲット用のYocto Linuxのビルド作業は一旦終了です。近いうちにターゲットを入手する予定なので、実機環境が整ったら、今回の作業で生成したイメージを使ってターゲットによる動作確認をやるつもりです。
posted by とみやん at 09:42| Comment(0) | TrackBack(0) | Embedded Linux > Yocto Project

2014年09月19日

Yocto Projectの研究を始めました

9月も後半に入って東京はさらに涼しくなってきました。残暑はほとんど感じられず本当に涼しい夏でした。私はまだ一日中半袖の服装で過ごしていますが、常駐先の会社に通うために朝部屋を出ると肌寒く、ここ数日は長袖の服がほしくなってきました。東京へ来たのは8月初旬だったので半袖の衣服をまったく持ってきません。一度塩尻に戻って秋冬用の服を持ってくるか、こちらで長袖の服を買うかしなければなりません。東京がこの涼しさなら信州はさらに涼しいはずで、もはや完全に秋の気候になっているのでないかと思います。

さて、またしても新しい研究テーマに遭遇して、仕事の関係でどうしても他より優先してこれに取り組まざるをえなくなりました。Yocto Projectがそれです。Yocto Projectは組込みLinuxベースのシステム開発の容易化と様々なアーキテクチャー間で移植できるようにすることを目標に発足したオープンソース・プロジェクトです。BeagleBoardやRaspberry Piに対応し、最近だとGalileo(Intelが2013年10月に発表した、Quark X1000を搭載したArduino互換開発ボード)へも移植されています。いままで半導体ベンダーやシステムベンダー、オープンソースコミュニティなどがそれぞれ独自に組込みLinuxディストリビューションを開発しており、これら間の連携はほとんどありませんでした。このような状況を改善するために、複数の企業やコミニティーが協力し合って組込みLinuxのスタンダードを創ろうとしているのがYocto Projectです。

Yocto Projectが発足したのは2010年ですが、私が本格的に組込みLinuxに取り組み始めたのも丁度同じ時期です。Yocto ProjectではOpenEmbeddedというビルドシステムが採用されていますが、これはAngstrom Linuxでも使われています。以前BeagleBoardでAngstrom Linuxを動かしたことありますが〔2012/12/29の記事〕、このときにAngstrom Linuxのサイトに情報とリンクが掲載されているのを見つけのがYocto Projectについて知った最初です。

じつは、本業の仕事でもいまYocto Linuxの研究開発をやっています。本業の仕事の関係でYocto Linux周辺の色々な情報を調べていくうちに、IntelのE38xx(Bay Trail-I)シリーズが組み込み用途で有望なプロセッサであることが判ってきました。Intel E38xx Atomシリーズは最新版省電力コアのSoCプロセッサで、多くのタブレットで採用されているZ37xxシリーズ(Bay Trail-T)と合わせて、Intelはいまこの2種類のプロセッサを組み込み分野向けに強力にアピールしています。Bay Trailは64ビッド・プロセッサで、その省電力性能は他社のARMコア・プロセッサを凌駕しています(あの超省電力Haswellコアを製造している半導体メーカー・トップのIntel製のプロセッサですから)。x86プロセッサなのでMicrosfotのWindows 8は当然動きます。Lenovo、ASUS、AcerなどがZ37xxを搭載した多様なタブレット製品を販売しています。また、同プロセッサを搭載したMinnowBoard MAX(BeagleBoardやPandaBoardを企画・製造したCircuitCoによる最新ボード、価格はUS$99)も登場して話題を集めています。さらに、Googleと協力しながらIntelが自ら開発を主導してAndroidをBay Trailへ移植し、同OSを搭載したタブレットもすでに登場しています。ASUSのMeMO PadFonepadがそれで、ユーザーの評価も高いようです。

 【西川和久の不定期コラム】ASUS「MeMO Pad 7」 〜Bay Trail-Tを搭載し、小型軽量化した7型Androidタブレット - PC Watch
 ASUS「MeMO Pad」が人気タブレットの1・2位を独占する理由とは? 日経トレンディネット
 【笠原一輝のユビキタス情報局】Bay Trailが実現する、WindowsとAndroidが共存するタブレット 〜x86版Androidで互換性の問題が非常に少ない理由 - PC Watch

Intelのアナウンス情報によると、64ビット版Androidの移植も順調に進んでいるようです。64ビット版AndroidはARMとx86版がほぼ同時にリリースされそうです。このようにBay Tailを周る動きが非常に活発なため、いま組込み業界の企業やエンジニアもこのプロセッサに注目しています。

余談になりますが、Intelはここ数年組込み分野向けのプロセッサやソフトウェア開発に非常に力をいれているようです。Atomシリーズを代表として、モバイル機器向けのプロセッサを次々に発売したり、組込みLInuxやAndroidの開発にも大きなエンジニアリング・リソースを投入したりしています。上の3番目の記事には、GoogleよりIntelの方が主導権を持ってx86版Androidの開発を進めている状況がうかがえる内容が書かれていて、なかなか興味深いです。PCの出荷台数が減少の一途を辿っているのに対してモバイル機器の出荷台数は増大しています。いいまでIntelはPC向けのプロセッサを主力製品として展開しており、モバイル分野ではARMコア・プロセッサを製造している半導体メーカーにシェア拡大を許してきましたが、ここに来て、モバイル分野でのシェアを獲得するためIntelは大攻勢に出ているようです。組込み業界の企業やエンジニアは、ARMコア・プロセッサを主力製品に持つ半導体メーカーとその周辺の動きをウォッチしていれば済んでいましたが、いまやIntelも組込み分野のメインプレーヤの一人になっています。これからはIntelの動向もウッチしていかないと、組込み分野の最新トレンドをフォローすることは難しくなるのではないでしょうか(すでに、そうなっているようですが・・・)。マイコン創世記からIT業界で仕事をしている私にとってはx86アーキテクチャの方が馴染みが深いですし、同じように感じているベテランのエンジニアは多いじゃないかと思います。「ARMからx86への回帰」が大きな潮流になりつつあるような気がしてなりません。

研究着手の事始めとして、取りあえず、Yocto Projectが配布している組込みLinuxディストリビューションのビルドに挑戦してみました。Yocto Projectはオープンソースプロジェクトなので、その成果は公式サイトですべて公開されています。Yocto Projectが配布しているディストリビューションにはQEMU(オープンソースのプロセッサエミュレータ)用のBSP(Board Support Package)が収納されているそうです。下調べで得た情報から、このQEMUターゲット向けのビルドはすぐに始めることができ、Linuxホスト上で簡単に動作確認ができるらしいです。QEMUターゲット用Yocto Linuxのビルドと動作テストを実際にやってみたので、以降にその作業記録を書いていきます。Yocto Projectの公式サイトに掲載されている「Yocto Project Quick Start 1.6.1」というページの内容を参照にしながら、以下の作業を進めていきました。開発ホストOSはUbuntu 12.04.1 32ビット版を使いました(Yocto Linuxが対応しているホスト・ディストリビューションの一覧はこちらに掲載されています。また、64ビット版Ubuntuを使わなかった理由については後日別の記事で説明します)。

■ Yocto Linuxビルド環境のセットアップ


まず最初に、Yocto Linuxをビルドするのに必要となるUbuntuホスト側のパッケージをインストールしました。
$ sudo apt-get install gawk wget git-core diffstat unzip texinfo gcc-multilib build-essential chrpath libsdl1.2-dev xterm

次に、Yocto Projectの公式サイトからYocto Linuxディストリビューションの最新バージョンYP Core - Daisy 1.6.1のパッケージファイルをダウンロードして、それを展開しました。
$ wget http://downloads.yoctoproject.org/releases/yocto/yocto-1.6.1/poky-daisy-11.0.1.tar.bz2
$ tar -jxvf poky-daisy-11.0.1.tar.bz2
$ cd poky-daisy-11.0.1

上のパッケージを展開すると、「poky-daisy-11.0.1」というディレクトリが作成されます。Yocto Linuxの全ソースはこの中に格納されています(正確には、このディレクトリに格納されているのはソースではなくレシピです)。

■ QEMU x86ターゲット用ビルド環境の準備


これ以降、QEMUをターゲットとしてYocto Linuxをビルドしていきますが、その前に、ビルド用の作業ディレクトリを作成しました。この処理のためのoe-init-build-envという専用シェルスクリプトが用意されているので、これを利用してQEMUターゲット用ビルド作業ディレクトリを作成しました。
$ source oe-init-build-env qemux86
You had no conf/local.conf file. This configuration file has therefore been
created for you with some default values. You may wish to edit it to use a
different MACHINE (target hardware) or enable parallel build options to take
advantage of multiple cores for example. See the file for more information as
common configuration options are commented.

The Yocto Project has extensive documentation about OE including a reference manual
which can be found at:
http://yoctoproject.org/documentation

For more information about OpenEmbedded see their website:
http://www.openembedded.org/

You had no conf/bblayers.conf file. The configuration file has been created for
you with some default values. To add additional metadata layers into your
configuration please add entries to this file.

The Yocto Project has extensive documentation about OE including a reference manual
which can be found at:
http://yoctoproject.org/documentation

For more information about OpenEmbedded see their website:
http://www.openembedded.org/



### Shell environment set up for builds. ###

You can now run 'bitbake <target>'

Common targets are:
core-image-minimal
core-image-sato
meta-toolchain
adt-installer
meta-ide-support

You can also run generated qemu images with a command like 'runqemu qemux86'

oe-init-build-envはYocto Linuxのビルド時に参照される環境変数の設定も行っています。このスクリプトを実行すると、パラメータで指定したディレクトリが作成された後、自動的にそのディレクトリへ移動します。ディレクトリを指定しないで実行した場合は、デフォルトで「build」という名前のディレクトリが作成されるようになっています。32ビット版QEMU x86をターゲットとしてYocto Linuxをビルドするので、上では、明示的に作業ディレクトリの名前を指定しました。

oe-init-build-envスクリプトで作成されたディレクトリの中身を確認すると、以下の3つのファイルが格納されていました。これらのファイルも同スクリプトによって自動的に作成されるようです。
  • conf/bblayers.conf
  • conf/local.conf
  • conf/templateconf.cfg

上のうちlocal.confの中に、ターゲットのビルド時に適用される全般的な共通設定項目が定義されています。このファイルの中を覗くと、下のような定義が存在することに気づくでしょう。
# This sets the default machine to be qemux86 if no other machine is selected:
MACHINE ??= "qemux86"

この「MACHINE」という設定項目がビルド対象ターゲットの定義です。上記のとおり、すでに「qemux86」となっているので、このままビルドすれば32ビット版QEMU x86用イメージを生成することができますが、その前にlocal.confに以下のような変更を加えました。
--- local.conf.orig	2014-09-18 13:54:55.989634472 +0900
+++ local.conf 2014-09-18 13:56:15.779639842 +0900
@@ -17,18 +17,18 @@
# These two options control how much parallelism BitBake should use. The first
# option determines how many tasks bitbake should run in parallel:
#
-#BB_NUMBER_THREADS ?= "4"
+BB_NUMBER_THREADS ?= "4"
#
# Default to setting automatically based on cpu count
-BB_NUMBER_THREADS ?= "${@oe.utils.cpu_count()}"
+#BB_NUMBER_THREADS ?= "${@oe.utils.cpu_count()}"
#
# The second option controls how many processes make should run in parallel when
# running compile tasks:
#
-#PARALLEL_MAKE ?= "-j 4"
+PARALLEL_MAKE ?= "-j 4"
#
# Default to setting automatically based on cpu count
-PARALLEL_MAKE ?= "-j ${@oe.utils.cpu_count()}"
+#PARALLEL_MAKE ?= "-j ${@oe.utils.cpu_count()}"
#
# For a quad-core machine, BB_NUMBER_THREADS = "4", PARALLEL_MAKE = "-j 4" would
# be appropriate for example.

Yocto Linuxのビルドはbitbakeというコマンドを用いて行いますが、上の「BB_NUMBER_THREADS」と「 PARALLEL_MAKE」はbitbakeコマンドの並列スレッド数とmakeコマンドの並列ジョブ数を決める設定項目です(makeはbitbakeから呼び出されます)。これらを適切な値に設定すると、ターゲットイメージのビルド時間を大きく短縮することができます。ググって調べると、makeの並列ジョブ数の適切値については以下の2つの説が存在するようです。
  1. 論理プロセッサコア数と同じ値にする
  2. 論理プロセッサコア数の2〜3倍の値にする
上の変更前のlocal.confの内容は前者の説に従った設定になっています。今回は論理コアを2個に設定したVMware Fusionの仮想マシン上で開発ホストOSのUbuntuを動かしています。私の経験によると、論理プロセッサのコア数が2の場合はmake並列ジョブ数を4に設定するのが最適であるという結果を得ています。local.conf内の「BB_NUMBER_THREADS」と「 PARALLEL_MAKE」の値をいずれも「4」に変更したのは、この理由からです。

■ QEMU x86用ターゲットイメージのビルド


これで、Yocto Linuxをビルドするための準備が整いました。oe-init-build-envスクリプトを実行したときのメッセージにも表示されていますが、Yocto Linuxの配布パッケージの中にはいくつかの定義済みイメージ・レシピが収納されています。「Yocto Project Quick Start 1.6.1」に記載されている内容に従って、最初にcore-image-sato(Sato Mobile Desktop)というイメージをビルドしてみました。これはモバイル機器向けQt/X11 GUIイメージです。「Yocto Project Quick Start 1.6.1」には、「bitbake -k core-image-sato」というコマンドによってターゲットイメージを生成できると書いてありますが、ここでは、先に次のコマンドを実行しました。
$ bitbake -c fetchall core-image-sato

ビルド対象イメージのcore-image-satoには、Linuxカーネル、X11、Qtなどサイズの大きいコンポーネントが構成要素として含まれています。「bitbake -k core-image-sato」というコマンドは、これらのソースを自動的にダウンロードしながらコンパイルとリンクを行い、最終的なターゲットイメージを生成します。core-image-satoの全構成要素のソースをまとめると相当なボリュームになるので、ソースのダウンロードとビルドの工程は分離した方が賢明です。上のコマンドによって、ターゲットイメージのビルドに必要なソースの取得だけを行うことができます。ソースのダウンロードにかかる時間は当然インターネット回線の速度に依存します(WiMAX 2+モバイルルータ経由の回線でこの処理を行いましたが、約40分かかりました。

全ソースをダウンロードしたら、いよいよYocto Linuxのターゲットイメージをビルドできます。以下のコマンドを実行して、ターゲットイメージcore-image-satoをビルドしました。
$ bitbake core-image-sato

ターゲットイメージのビルドに要する時間は、その中に含まれるコンポーネントの数とボリュームによって大きく変化します。また、開発ホストPCの性能にも依存します。私の環境では、core-image-satoのビルドになんと約18時間もかかかってしまいました(Intel Core i5 1.4GHz HyperThreading 2コア、メモリ2GB、ストレージ SSDという構成のVMware仮想マシンの場合)。ググって得た下調べ情報によると、Yocto Linuxのビルドは時間がかかると書かれているページが結構ヒットしたので覚悟はしていたのですが、ビルド時間に18時間にもなるとは予想をはるかに超えていました(さすがに18時間はかかりすぎではないかという気がので、これは計測結果では正確ではないかもしれません。夕方からビルドをスタートして、外部モニタの電源を切った状態で就寝してしまったので、もしかすると途中でMacがスリープ状態に入っていた可能性があります)。やはりクロック速度2.0GHz以上、HyperThreading 4コア以上のプロセッサを搭載したPCや仮想マシンでないと、X11やQtのビルドは厳しいということを思い知りました(この現実に直面して、俄然MacBook Pro Retinaが欲しくなってきました。MacBook Proに搭載されているプロセッサはすべて2.0GHz以上でMacBook Airのそれよりずっと高速だからです)。

■ QEMU x86用ターゲットイメージの動作確認


ターゲットイメージcore-image-satoのビルドが終わったので、さっそくその動作確認をやってみしました。以下のコマンドによって、QEMUでターゲットイメージを起動することができます。
$ runqemu qemux86

QEMUが起動すると新しいウインドウが開き、その中にお馴染みのLinuxのブートシーケンスが表示されました。そして、数秒後にQEMUウインドウの画面は下のような表示に変わりました。
UBShot_20140919_093147-Building_Yocto_Linux_1.6.1_for_QEMU_x86-1280x960
VMwareと同じように、Yocto Linuxのターゲットイメージcore-image-satoはQEMUの仮想マシン上で実行されています(実際の私の開発環境は、Mac OS X ⇒ VMware Fusion上のUbuntu ⇒ QEMU上のYocto Linuxと三重の画面の入れ子になっているので面白いです)。QEMU内のDesktopウィンドウの左上の三角をクリックすると、その画面は下のように変わりました。
UBShot_20140919_094437-Building_Yocto_Linux_1.6.1_for_QEMU_x86-640x480.png
この画面に表示されているのがSato Mobile Desktopの全アイテムのようです。ゲームまで在るのは面白いですが、かなりシンプルな構成ですね。

この中に「X11VNC Server」というアイコンが存在していますが、これはVNCサーバーみたいです。こいつがちゃんと動くのか興味があったので試してみました。まず、このSato Mobile Desktopの「X11VNC Server」アイコンをクリックして実行状態にしました。そして、Ubuntu側で別のターミナル・ウィンドウを開き、そこ中から以下のコマンドを入力しました。
$ sudo apt-get install vncviewer
$ vncviewer 192.168.7.2

最初のコマンドで、TightVNCというVNCクライアントのパッケージ(「vncviewer」はxtightvncviewerのエイリアス・パッケージ名です)をUbuntuへインストールしています。その後、QEMU上で動いているSato Mobile DesktopのVNCサーバーのIPアドレスを指定して、TightVNCを起動しています(コマンド「runqemu qemux86」でQEMUを起動した際に表示されるIPアドレスが、VNCサーバーのIPアドレスに相当します)。下のように、ちゃんとSato Mobile DesktopのVNCサーバーに接続できることを確認できました。
UBShot_20140919_094821-Building_Yocto_Linux_1.6.1_for_QEMU_x86-1280x960
これで、QEMU x86ターゲットのYocto Linuxのビルドと動作確認は終わりです。core-image-satoイメージのビルドにやたらと時間がかかることを除いて、特に問題に遭遇することはありませんでした。組込みLinuxのビルドと動作確認では大抵何かしらの問題に遭遇して、その解決方法をGoogle先生に教えてもらたりするのですが、今回の作業ではそれはなくスムーズにゴールまで到達できました(こういう問題にぶつかりながらゴールに辿り着いた瞬間に味わえる感激が組込みLinux開発の醍醐味なので、スムーズすぎると何だか物足りないですね)。QEMU x86はYocto Linuxのリファレンスターゲットらしいので、そのBSPはしっかりメンテナンスされているのでしょう。他の実機ターゲットでは、こういう風にスムーズにいくことはないんじゃないかと想像します。

近いうちにBay Trailプロセッサを搭載したターゲットボードを入手する予定なので(ググって情報収集をしていますが、Bay Trail搭載ハードはMini-ITXボードやベアボーンの方が入手性が良いみたいです)、そのときに改めてBay Trail向けYocto Linuxのビルドに挑戦します。また、BeagleBoardやPandaBoardへも移植されているようです。この2つはすでに入手済みなので、これらのボードでもYocto Linuxを動かしてみるつもりです。本業の仕事でYocto Linuxの研究開発をやっているので、こちらで得られた情報もこれから公開していくつもりです(守秘義務に触れるものは公開できないので、パブリックな情報やTipsなどになりますが・・・)。Yocto Linuxを使って特定用途向けのシステムを構築するにはレシピのカスタマイズや作成が必須の作業になりますが、これらの情報もぜひ提供したいと思っています。これからしばらくYocto Linuxの記事が続くことになるでしょう。

【2014/09/22 追記】

core-image-satoというイメージを使ってYocto Linuxのビルドと動作確認を行いましたが、Yocto Linuxの配布パッケージにはこれ外にもいくつかイメージ・レシピが収納されています。利用可能なイメージ・レシピの一覧は次のコマンドで確認することができます。
$ bitbake-layers show-recipes "*-image-*"
Parsing recipes..done.
=== Available recipes matching *-image-*: ===
core-image-base:
meta 1.0
core-image-clutter:
meta 1.0
core-image-directfb:
meta unknown (skipped)
core-image-full-cmdline:
meta 1.0
core-image-lsb:
meta unknown (skipped)
core-image-lsb-dev:
meta unknown (skipped)
core-image-lsb-sdk:
meta unknown (skipped)
core-image-minimal:
meta 1.0
core-image-minimal-dev:
meta 1.0
core-image-minimal-initramfs:
meta 1.0
core-image-minimal-mtdutils:
meta 1.0
core-image-rt:
meta 1.0
core-image-rt-sdk:
meta 1.0
core-image-sato:
meta 1.0
core-image-sato-dev:
meta 1.0
core-image-sato-sdk:
meta 1.0
core-image-testmaster:
meta 1.0
core-image-testmaster-initramfs:
meta 1.0
core-image-weston:
meta 1.0
core-image-x11:
meta 1.0

Sato Mobile DesktopはQt/X11ベースGUI環境なので、いじくり回して楽しめます。せっかく動かすならこういうの面白味のある奴が良いのですが、core-image-satoはビルドにとても時間がかかるのがネックです。もっと手っ取り早くYocto Linuxの動作確認までやりたい場合は、core-image-minimalというイメージを使うことをお勧めします。これはコンソール・ベースのCLI環境で最小構成のイメージなので、ビルド時間を短縮できます。実際に、このcore-image-minimalのビルドと動作確認をやってました。まず以下のコマンドによって、core-image-minimalのビルドに必要な全ソースをダウンロードしました。
$ time bitbake -c fetchall core-image-minimal
Loading cache: 100% |###############################################################| ETA: 00:00:00
Loaded 1222 entries from dependency cache.
NOTE: Resolving any missing task queue dependencies

Build Configuration:
BB_VERSION = "1.22.0"
BUILD_SYS = "i686-linux"
NATIVELSBSTRING = "Ubuntu-12.04"
TARGET_SYS = "i586-poky-linux"
MACHINE = "qemux86"
DISTRO = "poky"
DISTRO_VERSION = "1.6.1"
TUNE_FEATURES = "m32 i586"
TARGET_FPU = ""
meta
meta-yocto
meta-yocto-bsp = "<unknown>:<unknown>"

NOTE: Preparing runqueue
NOTE: Executing RunQueue Tasks
NOTE: Tasks Summary: Attempted 166 tasks of which 164 didn't need to be rerun and all succeeded.

real 0m8.740s
user 0m3.984s
sys 0m4.008s

「time」コマンドを付加して時間を計測してみましたが、core-image-minimalのソース取得は一瞬で終了しました。上のメッセージを読むと、実際には2つの処理タスクしか実行されていないことが判ります。core-image-minimalを構成する全ソースはcore-image-satoの取得済みソースに含まれているからじゃないかと思います。

続いて、core-image-minimalイメージのビルドを行いました。
$ time bitbake core-image-minimal
Loading cache: 100% |###############################################################| ETA: 00:00:00
Loaded 1222 entries from dependency cache.
NOTE: Resolving any missing task queue dependencies

Build Configuration:
BB_VERSION = "1.22.0"
BUILD_SYS = "i686-linux"
NATIVELSBSTRING = "Ubuntu-12.04"
TARGET_SYS = "i586-poky-linux"
MACHINE = "qemux86"
DISTRO = "poky"
DISTRO_VERSION = "1.6.1"
TUNE_FEATURES = "m32 i586"
TARGET_FPU = ""
meta
meta-yocto
meta-yocto-bsp = "<unknown>:<unknown>"

NOTE: Preparing runqueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
NOTE: Tasks Summary: Attempted 1791 tasks of which 1786 didn't need to be rerun and all succeeded.

real 1m19.636s
user 0m34.502s
sys 0m28.878s

こちらもたった1分で終わってしまいました。core-image-satoで全レシピがすでにビルド済みなので、レシピから生成済みのパッケージを組み合わせてcore-image-minimalのrootfsを構築する処理だけが実行されたようです。ちなみに、bitbakeコマンドによって生成されるカーネルやrootfsのイメージは<build_dir>/tmp/deploy/images/qemux86というディレクトリに格納されます。
$ ls tmp/deploy/images/qemux86
bzImage
bzImage--3.14+git0+09424cee64_f9048769cc-r0-qemux86-20140918062211.bin
bzImage-qemux86.bin
core-image-minimal-qemux86-20140922002131.rootfs.ext3
core-image-minimal-qemux86-20140922002131.rootfs.manifest
core-image-minimal-qemux86-20140922002131.rootfs.tar.bz2
core-image-minimal-qemux86.ext3
core-image-minimal-qemux86.manifest
core-image-minimal-qemux86.tar.bz2
core-image-sato-qemux86-20140918062211.rootfs.ext3
core-image-sato-qemux86-20140918062211.rootfs.manifest
core-image-sato-qemux86-20140918062211.rootfs.tar.bz2
core-image-sato-qemux86.ext3
core-image-sato-qemux86.manifest
core-image-sato-qemux86.tar.bz2
modules--3.14+git0+09424cee64_f9048769cc-r0-qemux86-20140918062211.tgz
modules-qemux86.tgz
README_-_DO_NOT_DELETE_FILES_IN_THIS_DIRECTORY.txt

core-image-minimalのイメージがビルドができたので、それをQEMUで起動してみました。core-image-satoと同じ「runqemu qemux86」というコマンドでQEMUを起動できます。
UBShot_20140922_124157-Building_Yocto_Linux_1.6.1_for_QEMU_x86-1280x960
QEMUを使って動作確認までできるのはすごく便利そうです。実機ターゲットがなくても、大抵のアプリはデバッグができてしまうからです。実機固有のハードウェアに依存するアプリは無理ですが、QEMU仮想マシンはEthernetもエミュレートしてくれるので、ネットワーク・アプリまでQEMU上で動かすことが可能です。VMwareほど完成度の高い仮想環境ではないみたいですが、結構広く使われているので、十分に実用に耐えられる環境なのではないかと思います。QEMUはx86だけでなくARMやPowerPCにも対応しているので、組込みLinuxでこそ真価を発揮するエミュレータです。組込みLinuxの開発環境にQEMUを統合化したことは、Yocto Projectによる大きな成果の一つだと言えます。


posted by とみやん at 10:20| Comment(0) | TrackBack(0) | Embedded Linux > Yocto Project