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

2014年09月16日

Xcode 5.1.1のMountain Lionへのインストール

東京も曇ってすっきりしない日々が続いてましたが、先週末の連休からやっと晴れて良い天気になりました。例年ならこの時期は残暑が厳しく蒸し暑いのですが、今年はそれほど暑さが辛くありません。湿度が低いようで、晴れても爽やかさを感じられます。本当に夏らしい気候だったのは、東京では7月中旬〜8月中旬の一ヶ月だけでした。9月も残り2週間ですが、秋の兆しは早く訪れそうです。

さて、前記事に書いたとおり、新型のMacBook Air 11-inchを手に入れたので、いまこれにiOS開発環境を構築中です。ADC(Apple Develper Connection)で配布されているXcodeは、そのリリース時点の最新バージョンと一つ前のバージョンのOS Xに対応しています。MBA11のOSはMountain Lionにダウングレードしたのは、Yosemiteの評判が良くなく開発環境として使うことに不安があったからですが、最新版のXcodeがMountain Lionに対応していたことも判断基準になりました。現時点のXcodeの最新バージョンはXcode 5.1.1ですが、これはOS X YosemiteとMountain Lionで使うことができます。Xcode 5.1.1をMBA11へインストールしたので、自分の備忘録を兼ねて、その作業記録を書いておきます。

MBA11にiOS開発環境を構築するにあたって、Xcode 5.1.1より先にXcode 4.6.3をインストールしました。この2つのバージョンを共存させて併用したかったからです。Xcode 5.1.1はiOS 7.0, 7.1、Xcode 4.6.3はiOS 5.0〜6.1開発用として使い分けていくつもりです。去年Mac mini(Mountain Lion搭載)へXcode 4.6.3を入れましたが、このときと完全に同じ手順でインストールを行いました。Xcodeアプリを「アプリケーション」フォルダへコピーした後、追加コンポーネントとドキュメントのインストールを行い、最後に他のバージョンのXcodeからiOS 5.0, 5.1, 6.0 SDKとMac OS X 10.6 SDKをコピーしました(2014/07/08の記事を参照)。下のスクリーンショットが、Xcode 4.6.3をインストールしてiOS/Mac OS X SDKを追加した後のDeveloper Information([ユーティリティ]>[システム情報]の「Developer」カテゴリ)表示です。
SCShot_140915_0001-Installing_Xcode_4.6.3_on_MountainLion-751x520
上の作業が済んだ後、Xcode 4.6.3のアプリファイルXcode.appXcode_463.appへリネームした上で、Xcode 5.1.1のインストールを始めました。

まずはXcode 5.1.1のアプリファイルを「アプリケーション」フォルダへコピーしました。
SCShot_140915_0007-Installing_Xcode_5.1.1_on_MountainLion-612x421.png
コピーが終わった後Xcode 5.1.1を初めて起動すると、ライセンス同意要求のウィンドウに続いて、下のようなウィンドウが表示されました。
SCShot_140915_0011-Installing_Xcode_5.1.1_on_MountainLion-479x162.png
このウィンドウの「Install」ボタンを押すと、追加コンポーネントのインストールが始まりました。
SCShot_140915_0013-Installing_Xcode_5.1.1_on_MountainLion-479x162.png
この処理が終了すると、XcodeのWelcomeウィンドウが表示されました。
SCShot_140915_0014-Installing_Xcode_5.1.1_on_MountainLion-801x472
Xcode 5.1.1が起動することを確認したら、すぐに[Xcode]>[Preferences]メニューの[Downloads]タブ画面を開き、コンポーネントとドキュメントの追加インストールを行いました。
SCShot_140915_0017-Installing_Xcode_5.1.1_on_MountainLion-750x498
SCShot_140915_0028-Installing_Xcode_5.1.1_on_MountainLion-750x498
すべてのコンポーネントを追加した後のXcode 5.1.1のDeveloper Informationは下のような表示になりました。
SCShot_140915_0020-Installing_Xcode_5.1.1_on_MountainLion-751x573
これでXcode 5.1.1のインストールは一応完了ですが、上のスクリーンショットから本バージョンにはiOS 7.1 SDKしか同梱されていないことが判ります。iOS 7.0用アプリの開発も行いたいので、Xcode 5.1.1にiOS 7.0 SDKを追加しました。具体的には、Xcode 5.0.2のdmgファイルをマウントして、ターミナルから次のコマンドを実行すれば、iOS 7.0 SDKを追加できます。
$ sudo cp -Rp /Volumes/Xcode/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.0.sdk /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs

下のスクリーンショットが、iOS 7.0 SDKを追加した後のXcode 5.1.1のDeveloper Information表示です。
SCShot_140915_0022-Installing_Xcode_5.1.1_on_MountainLion-751x573
さらに、iOS 5.0〜6.1とMac OS X 10.6, 10.7のSDKをXcode 5.1.1へ追加する作業も行いました(以下は、2013/12/03の記事に書いたMac miniのMountain LionへXcode 5.0.2をインストールしたときと同じ手順ですが、再掲載しておきます)。
  1. ターミナルを開き、次のコマンドを実行して、Xcode 5.1.1内にXcode 4.6.3側のiOS SDKが格納されているディレクトリのリンクを作成しました。
    % cd /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs
    % ln -s /Applications/Xcode_463.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS5.0.sdk ./
    % ln -s /Applications/Xcode_463.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS5.1.sdk ./
    % ln -s /Applications/Xcode_463.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.0.sdk ./
    % ln -s /Applications/Xcode_463.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk ./

    これによって、iOS 5.0, 5.1, 6.0, 6,1のSDK が追加されます。

  2. 続いて、次のコマンドを実行して、Xcode 5.1.1内にXcode 4.6.3側のMac OS X SDKが格納されているディレクトリのリンクを作成しました。
    % cd /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs
    % ln -s /Applications/Xcode_463.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.6.sdk ./
    % ln -s /Applications/Xcode_463.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk ./

    これによって、Mac OS X 10.6, 10.7のSDKが追加されます。

上のすべての操作を行った後、Xcode 5.1.1のDeveloper Information表示を確認すると、下のようになっていました。
SCShot_140915_0024-Installing_Xcode_5.1.1_on_MountainLion-751x612
上記のとおり、MBA11へXcode 4.6.3とXcode 5.1.1を共存インストールしてiOS開発環境を構築しましたが、その前に基本的なソフトを入れる作業もやりました。Windowsと比較すると、Macはこの作業がすごく楽です。基本的なソフトを一通り入れて使える状態にするのに、Windowsだと2〜3日かかったりしますが、Macだと半日〜1日で終わります。Windowsではソフト毎にインストーラを起動して入れていきますが、インストーラが起動するまで数分待たされたりしますし、インストール手順も統一性がなくまちまちです。インストーラによって表示されるガイド画面を確認しながら慎重に作業を進めていかないと、不要なものまでインストールされたりします。これに対して、Macではアプリのアイコンを「アプリケーション」フォルダへコピーするだけでインストールできます。すべてのアプリがこの手順に統一されているので、dmgファイルを開いたりzip/bz2ファイルを解凍した後にこの操作を行うだけです。ドライバやカーネルモジュールを内包しているソフトではインストーラが用意されていますが(インストーラはpkg/mpkgファイル内に収納されているので、同ファイルを開くと自動的に起動します)、インストーラのガイド画面もほぼ統一されているので、インストール操作を誤ったり迷ったりすることはまずありません。Windowsでは新しいソフトを入れるだけでシステムが不安定になったりすることがあり、こういう現象を解決するのに時間を取られたりしますが、Macではこんなことは皆無です。私は数台のMacを4年間ほぼ毎日を使い続けていますが、いままでこういう経験をしたことが一度もありません。マルウェアの数と種類もWindowsの方が断然多く、アンチウィルスやファイアーウォールを入れていないWindows PCはすぐにマルウェアに感染してしまいます。OSの安定性と安全性では、WindowsよりMacの方が圧倒的に優れています。本業の仕事でWindowsに使っていると、画面のあまりの見難さ(Macと比較すると、Windowsは特にフォントがすごく醜いです)とあまりの使い難さに嫌気が差してきます。毎日Macだけ使って仕事ができたら、どんなに幸せだろうと思ってしまいます。
タグ:Xcode
posted by とみやん at 10:58| Comment(0) | TrackBack(0) | 開発・プログラミング > Mac

2014年09月06日

MacBook Air 11-inch(Early 2014)を入手した

久しぶりに大物の買い物をしてしまいました。新しいPCを手に入れたのです。私にとってPCとはMacのことです。本業の仕事では仕方なくWindows PCを使っていますが、開発研究やプライベート用としてWindows PCを買うことなど、もはや頭の隅に浮かぶことさえありません。デスクトップのメインPCとして使っているMac mini(Mid 2011)を入手したのが2012年10月なので、PCを買ったのは約2年ぶりです。WindowsからMacに乗り換える前は年に2〜3台のPCを買っていましたが、いまはせいぜい年に1台位です。使用目的が変化する度に、PCを買い換えたり、CPUやメモリなどのパーツを集めてPCを組んだりしていました。いまはMacにしか興味がないので、WindowsやPCパーツの最新動向を追いかけることはまったくなくなりました。こういう情報を知らなければ、PCやパーツを買うためにお金を消費することもなくなります。おかげで、トータルでは以前よりもPC機材に使うお金が大分減りました。「MacはWindows PCよりも値段が高いので、なかなか買えない」と言う人が多いですが、パーツを集めて何台もWindows PCを組むより、Macを一台買った方がよっぽど経済的です。

2013年6月に超省電力のHarswellコアIntel Core i5プロセッサを搭載したMacBook Airが発売されて以来、ずっとこの新型MBAが欲しくてたまりませんでした。モデルチェンジによってプロセッサ性能はそれほど大きく向上していませんが、バッテリー駆動時間が大幅に伸びたことが羨ましくてたまらなかったからです。MBA11のMid 2011/2012とMid 2013/2014を比較すると、バッテリー駆動時間は5時間から9時間に伸びています。MBAは持ち歩いて使うことが多いモバイルPCなので、この改良点は他の何よりもすばらしい事だと思っていました。

今回私が入手したのは、MacBook Air 11-inchの最新モデルEarly 2014 MD712J/BをベースにカスタマイズされたCTO版です。マシンスペックはプロセッサIntel Core i5 1.4GHz,メモリ8GB,ストレージSSD 256GBで、キーボードはUS配列になっています。スペックの中で特に搭載メモリの容量にこだわりを持っていました。標準仕様のMBAの搭載メモリは4GBですが、これを8GBに拡張した奴がどうしても欲しかったのです。その理由は、本業の仕事や研究テーマの開発でParalles DestopやVMware Fusionの仮想マシンにLinuxを入れて使うことが多いからです。いままでMBA11 Mid 2011(Intel i7 1.8GHz,メモリ4GB,ストレージSSD 256GB)をノマド用メインPCとして使ってしまたが、これを今回入手したMBA11 Early 2014に換えました。一緒にHyperJuiceを持ち歩いたりしていましたが、これで予備バッテリーを持ち歩く必要はなくなります。プロセッサはi7 1.8GHzからi5 1.4GHzへ変わっていますが、プロセッサ・コアや内蔵GPUの性能も向上しているので、この2つはほとんど差はないと思います(コア数も物理1、HyperThreading 2で同じです)。それより、メモリ容量が4GBから8GBに倍増したことが大きいです。内蔵SSDの読み書き性能も大きく向上しているらしいので、使っていくうちにこれらの恩恵も実感できるじゃないかと期待しています。
IMG_20140818-Photo01-Apple_MacBookAir11-MD721JB_CTO.jpg
IMG_20140818-Photo04-Apple_MacBookAir11-MD721JB_CTO.jpg
IMG_20140818-Photo05-Apple_MacBookAir11-MD721JB_CTO.jpg
IMG_20140818-Photo06-Apple_MacBookAir11-MD721JB_CTO.jpg
IMG_20140818-Photo14-Apple_MacBookAir11-MD721JB_CTO.jpg
IMG_20140818-Photo15-Apple_MacBookAir11-MD721JB_CTO.jpg
手段はまたしてもオークション落札で、入手したのはワンオーナーの中古品です。発売されてまだ間もない最新モデルなので、ほぽ新品に近い状態でした。新型MacBook Airを入手するにあたって、11-inchと13-inchのどちらにするかずいぶん悩みましたが、ほぼ毎日持ち歩くPCなので、やはり軽さを重視して11-inchの方を選択しました。じつは、当初は13-inchの方を選択するつもりでした。ディスプレイ表示領域の広さを重視していたからです。11-inchが1399x768で13-inchは1440x900ですが、この差は大きいと考えていました。この考えはいまも変わっていませんが、重量とディスプレイ表示領域を天秤にかけて悩みに悩んだ末、結局11-inchの方を選択した訳です。私はMacBook Air 13-inch(Late 2010)も所有しており、こちらも何度も持ち歩いたことがありますが、13-inchの重さは結構ずっしりときます。バックパックに入れるとそれほど苦ではないのですが、手提げカバンではその重さを実感します。さらに移動距離の長さや持ち歩く頻度も大きく影響して、やはり13-inchのハンドキャリーは辛さを感じることが多かったです。11-inchは1.08kgなのに対して13-inchは1.35kgで270gしか差はありませんが、この差は意外に大きいというのが私の感想です。今回MBA 11-inchを選んだ理由はもう一つあります。それは、Retinaディスプレイを搭載した全面的なモデルチェンジ版のMacBook Airが今年中に発売されるのではないかという観測情報がたくさん流れていることです。ディスプレイのサイズは12-inchになりそうだという情報も多く、この予想どおりに、もしMacBook Air Retina 12-inchが登場すれば、それは軽さとディスプレイ表示領域の広さを兼ね備えた究極のノートPCになるはずです。これと現モデルのMBA 13-inchを比較すると、後者は見劣りします。市場価格も11-inchより13-inchの方が高いですし、いま無理して現モデルの13-inchを買うよりは、MacBook Air Retinaが発売されるのを待った方が賢明だと思いました。

今回入手したMBA11には最新版のOS X 10.9 Marvericksがプリインストールされていましたが、こいつはOS X 10.8 Mountain Lionにダウングレードしてしまいました。ググって調べると、Marvericksに対する評判があまり良くないようだったからです。メジャーなアプリを使うだけの実用機ならMarvericksでまったく問題ないと思いますが、開発機用に使うのはかなり不安を感じます。Marvericksも10.9.4までバージョンが進んでいますが、いまだにその評判は良くないみたいです。私は他のMacもMarvericksにアップグレードしていません。今年10月に新パーションのOS X 10.10 Yosemiteがリリースされるようですが、Yosemiteへのアップグレードも当面やるつもりはありません。
SCShot_140906_0001-MBA11_Early2014_MD721JB-OSX_MountainLion-1366x768
ちなみに、Moutain LionのインストールはDiskMager Xというソフトによって作成したUSBメモリを使って行いました。Mac App StoreからOS X(Lion/Mountain Lion/Marvericks)のアップグレード・アプリをダウロード済みの状態なら、このDiskMager Xを使って簡単にクリーン・インストール用メディアを作成することができます。Mac miniにMountain Lion用のアップグレード・アプリがダウンロード済みだったので、そちらにDiskMager Xを入れてMountain Lionのインストールメディアを作成しました。
タグ:MacBook Air
posted by とみやん at 14:17| Comment(0) | TrackBack(0) | PC > Mac