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