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