2015年03月27日

Tizenの研究を始めました

Yocto Projectの記事の中でTizenに興味を持っていることを書きましたが、いよいよTizenの研究を本格的に始めることにしました。

Tizenと言えばSamsung社を連想する人が多いようですが、TizenプロジェクトはLinux Foundation(Linuxオペレーティングシステムの普及をサポートする非営利のコンソーシアム)内に存在しており、Samsungは同プロジェクトの参加企業の一つでしかありません。また、Tizenの産業的役割を主導するために組織されたTizen Association という非営利団体が在り、こちらはアメリカのニュージャージー州に本部を置いています。TizenはAndroidに対抗するモバイルOSとして大きな注目を浴びた時期がありましたが、いまは主力分野をウェアラブル・デバイス、Smart TV、IVI(In-Vehicle Infotainment)などにシフトしています。モバイル・デバイスの向けのSDKやディストリビューションも開発が継続されていますが、TizenのUIはiOSやAndroidのようにまだ洗練されていません。

2015年1月にインド向けのSamsung Z1というスマホが発売されましたが(これの前にロシア向けのSamsung Zという機種が発表されましたが、発売延期になっています)、これがTizenを搭載した初めてのスマホです。これに対して、Firefox OSの方はすでに10機種以上が発売されています(そのほとんどは新興国向けの機種のようですが)。AndroidのライバルとなりそうなモバイルOSとしては、Firefox OSの方が一歩も二歩もリードしていると言って良いでしょう。Google検索のヒット数を比較すると、TizenよりFirefox OSの方が10倍も多いです。日本国内に限っても、NTTドコモが計画していたTizen搭載スマホの発売は延期された(Tizenスマホの開発は進めていたようですが、市場動向から大きな販売数は見込めないと判断したようです)のに対して、auからはFx0 LGL25というFirefox OS搭載スマホが2014年12月に発売されています(ただし、Fx0 LGL25の評判はあまり良くないようです)。これほどの差が開いてしまうと、もはやTizen勢が挽回するは難しいでしょう。

この2つのモバイルOSが登場した当初は私もFirefox OSを方に注目していたのですが、いまはどちらかと言うとTizenに対する興味の方が大きくなっています。Firefox OSへの興味も失った訳ではありませんが、Firefox OSがAndroidの資産をかなり流用していることが判ったことで、Firefox OSに対する熱は一気に冷めました。いまも進歩が続いているAndroidの成果を流用できるので現実的な選択であることは理解できますが、「それでは、Androidとどうやって差別化するのか」という疑問が生まれます。私は天邪鬼でマイナーなものにほど惹かれる傾向を持っていて、いまはFirefox OSよりTizenへの関心の方が強いです。

私がTizenに大きな興味を持つようになったもう一つの理由は、Tizenプロジェクトを主導している企業にIntelが含まれていることです。Yocto Projectもそうですが、Intelが主導者的な役割をしているプロジェクトを研究すると技術的に得られるものが大きいです。ただし、Intelが主導者的な役割をしているのはスマホ/タブレット向けのTizen(Tizen Mobile)ではなく、Tizen IVIの方のようです。前者を主導しているのはSamsungのようです。Samsung社はGalaxyシリーズのアクセサリという位置づけでGearシリーズという製品を販売していますが、その中の腕時計型製品にもTizenが搭載されています。こちらはTizen Wearableという名前で、そのSDK(Tizen SDK for Wearable)もTizen Developersのサイトで配布されています(ただし、Samsung Gearシリーズの評判はあまり芳しくないようです)。Intelが主導者的な役割をしているので完全に消滅してしまうことはないと思いますが、Tizenの将来は決して明るいとは言えないでしょう。

■ Tizen SDKのインストール


Tizen研究着手の第一段として、まずはTizen SDKをインストールしてみましました。ウェアラブル・デバイスやIVI用のTizen SDKも配布されていますが、無印のTizen SDKはモバイル・デバイス用の開発環境です。私が一番興味を持っているのはTizen IVIなのですが、アプリの動作環境や開発手法は他のデバイス向けのSDKと大きな差はなんいじゃないかと想像しています。開発者向けのTizen DevelopersというサイトでTizen SDKのMac OS X版が配布されているので(Ubuntu, Windows, Mac OS X版があります)、Tizenの概要を知るために、これをメインPCのMacBook Airへインストールしてみました。

Tizen SDKは、Tizen Developersサイトの以下のベージで配布されています。

 Tizen SDK | Tizen Developers

Tizen SDKを使うにはいくつかの前提条件があります。前提条件に関する詳しい情報は以下のベージに掲載されています。

 Prerequisites for the Tizen SDK | Tizen Developers

PCのスベックとしては、デュアルコア2GHz以上のCPU、3GB以上のメモリとなっていますが、ググって得た情報によると、CPUはCore i5クラス以上、メモリは4GB以上でないと、SDKに含まれているエミュレータが実用的な性能では動かないらしいです。今回Tizen SDKをインストールしたのはMacBook Air 11"(Early 2014)ですが、この条件を十分に満たしています。

Mac OS X版Tizen SDKのソフト環境の要件だけを記載すると、以下のような条件を満たしている必要があるようです。
  • Oracle版のJava 7以降がインストールされていること。
  • Command Line Toolsがインストールされていること。

Tizen SDKにはIDEが含まれていますが、これはEclipseをカスタマイズした物らしいです。EclipseはJavaベースのアプリケーションなので、Javaが必要になります。私の環境にはApple版のJava 6(JDK 1.6)はインストール済みでしたが、Oracle版のJavaはインストールしていませんでした。Tizen SDKのインストールを始める前に、OracleのサイトからJDK 1.7を入手して、Apple版JDK 1.6を残したままインストールしました(参考ページAにApple版とOracle版JDKの共存方法が掲載されていたので、このとおりにしました)。Command Line Toolsの方はXcode 5.1.1のインストール時に追加済みだったので、こちらの作業は必要ありませんでした。

下調べで得た情報によると、Tizen SDKのインストールは上記のベージで配布されている「Install Manager」という名前のインストーラを使って行うようです。このInstall ManagerによってTizen DevelopersのサイトからSDKイメージがダウンロードされるようですが、あらかじめダウンロードしておいたSDKイメージを使うこともできます。インターネット回線の速度に依存しますが、前者の方法だと最低でも数十分以上かかるみたいなので、私は後者の方法を選択しました。ちなみに、今回MacへインストールしたのはTizen 2.3 Rev2 SDK(本記事投稿時点の最新バージョン)です。

前提条件がすべて整っている状態になっていることを確認した後、さっそくTizen SDKのInstall Managerを起動してみました。
SCShot_150327_0003-Installing_Tizen_2.3_Rev2_SDK-MacOSX-452x256.png
Install Managerを起動すると、最初に下のようなウィンドウが表示されます。
SCShot_150327_0007-Installing_Tizen_2.3_Rev2_SDK-MacOSX-630x490.png
このままインスールを開始すると、SDKイメージはインターネット経由でダウンロードされるようです。ここでは、ローカルなSDKイメージを指定するために[Advanced]というリンクをクリックしました。すると、下のようなウィンドウが開きました。
SCShot_150327_0011-Installing_Tizen_2.3_Rev2_SDK-MacOSX-578x484.png
このウィンドウ内の[Package server]というのがインターネット経由でSDKイメージをダウンロードするオプションで、もう一方の[SDK image]がローカルなSDKイメージを使うオプションのようです。[SDK image]ラジオボタンを選択した上で、右側のフォルダ・アイコンをクリックするとファイル選択ダイアログが開いたので、あらかじめダウンロードしておいたTizen SDKのイメージファイルを指定しました。その上で[OK]ボタンを押すと、最初のウィンドウに戻りました。

SDKイメージの取得方法を選択した後、最初のウィンドウの[Install]アイコンをクリックして、Tizen SDKのインストール処理を開始しました。すると、下のようなウィンドウが表示されました。
SCShot_150327_0013-Installing_Tizen_2.3_Rev2_SDK-MacOSX-630x490.png
このウィンドウには2種類のインストール・プロファイルが表示されています。このままインストールを開始すると、[Mobile-2.3]というタイプのアプリを開発するための標準的なコンポーネントがインストールされるんだと思います。

インストールするコンポーネントを変更できるかどうかに興味があったので、ここでは[Custom]というボタンを押してみました。すると、ウィンドウは下のような表示に変わりました。
SCShot_150327_0014-Installing_Tizen_2.3_Rev2_SDK-MacOSX-630x490.png
どうやら、このウィンドウによってインストールするコンポーネントを個別に選択できるようです。下のウィンドウが[Typical]のコンポーネントの選択状態です。
SCShot_150327_0015-Installing_Tizen_2.3_Rev2_SDK-MacOSX-630x490.png
[Typical]のコンポーネントだけでも問題ないのかもしれませんが、ここでは、すべてのコンポーネントを選択状態にした上で、[Next]ボタンを押しました。
SCShot_150327_0016-Installing_Tizen_2.3_Rev2_SDK-MacOSX-630x490.png
すると、ライセンス条件への同意を求める下のようなウィンドウが表示されました。
SCShot_150327_0017-Installing_Tizen_2.3_Rev2_SDK-MacOSX-630x490.png
[I agree]ボタンを押すと、さらに下のようなウィンドウに変わりました。
SCShot_150327_0018-Installing_Tizen_2.3_Rev2_SDK-MacOSX-630x490.png
このウィンドウの[INSTALL]ボタンを押すると、Tizen SDKのインスール処理が開始されました。
SCShot_150327_0020-Installing_Tizen_2.3_Rev2_SDK-MacOSX-630x490.png
インストール処理が終了すると、最終的に下のようなウィンドウ表示になりました。
SCShot_150327_0021-Installing_Tizen_2.3_Rev2_SDK-MacOSX-630x490.png
これで、Tizen SDKのインストールは完了のようです。

インストール処理の開始直前のウィンドウに表示されているとおり、デフォルトでは、Tizen SDKは以下の2つのディレクトリへインストールされます(同ウィンドウ内の[Installation Location][Data Location]というリンクをクリックすることで、Tizen SDKのインストール先ディレクトリを変更するこも可能です)。
  • /Users/LOGINUSER/tizen-sdk
  • /Users/LOGINUSER/tizen-sdk-data

Tizen IDEの実行ファイルを探してみると、/Users/LOGINUSER/tizen-sdk/ide/IDE.appがそれのようです。
SCShot_150327_0022-Installing_Tizen_2.3_Rev2_SDK-MacOSX-910x474
インストール完了時のウィンドウに表示されている指示に従って、Macを再起動した後、このIDE.appという実行ファイルを起動してみました。すると、下のようなスプラッシュ・ウィンドウが表示されました。
SCShot_150327_0023-Installing_Tizen_2.3_Rev2_SDK_MacOSX-478x328.png
そして、しばらく待つと、下のようなウィンドウが開きました。Eclipseを使ったことのある人にはお馴染みのワーススペースの保存先ディレクトリを尋ねるウィンドウです。
SCShot_150327_0027-Installing_Tizen_2.3_Rev2_SDK_MacOSX-591x244.png
このウィンドウの[OK]ボタンを押すと、数秒後に下のようなウィンドウが開きました。
SCShot_150327_0030-Installing_Tizen_2.3_Rev2_SDK_MacOSX-1024x746
これが、Tizen IDEのWorkbenchウィンドウのようです。

本当はHello Worldアプリを作成して、それをエミュレータで実行するところまで書くつもりだったのですが、疲れてしまいました。Tizenのアプリ開発事始め的な内容は次の記事に書くことにします。

【2015/03/29 追記】

本記事にはTizen SDK 2.3 Rev2をMacBook Airへインストールした際の作業記録を書きましたが、Mac miniへもTizen SDKをインストールしてみました。こちらへインストールしたのは少し古いバージョンのTizen SDK 2.2.1 です。

この2つのバージョンのInstall MaganerとTizen IDEの画面にはだいぶん差がありました。参考のために、Tizen 2.2.1 SDKのMac OS X版をインストールした際のスクリーンショットを掲載しておきます。
SCShot_150329_0001-Installing_Tizen_2.2.1_SDK-MacOSX-628x478.png
SCShot_150329_0003-Installing_Tizen_2.2.1_SDK-MacOSX-578x484.png
SCShot_150329_0005-Installing_Tizen_2.2.1_SDK-MacOSX-578x484.png
SCShot_150329_0006-Installing_Tizen_2.2.1_SDK-MacOSX-578x484.png
SCShot_150329_0008-Installing_Tizen_2.2.1_SDK-MacOSX-578x484.png
SCShot_150329_0009-Installing_Tizen_2.2.1_SDK-MacOSX-578x484.png
SCShot_150329_0010-Installing_Tizen_2.2.1_SDK-MacOSX-578x484.png
SCShot_150329_0013-Installing_Tizen_2.2.1_SDK-MacOSX-578x484.png
SCShot_150329_0014-Installing_Tizen_2.2.1_SDK-MacOSX-578x484.png
Tizen 2.2.1 SDKでは、Tizen IDEの実行ファイル名はTizenIDE.appになっていました。
SCShot_150329_0016-Installing_Tizen_2.2.1_SDK-MacOSX-888x558
初めてTizen SDK 2.2.1 のIDEを起動すると、スプラッシュ・ウィンドウとワークスペースの保存先を尋ねるウィンドウに続いて、下のようなWelcomeウィンドウが表示されました。
SCShot_150329_0020-Installing_Tizen_2.2.1_SDK-MacOSX-1024x768
このウィンドウの[Workbench]というアイコンをクリックすると、Tizen IDEのWorkbenchウィンドウが開きました(2回目以降の起動ではWelcomeウィンドウは表示せれず、直接Workbenchウィンドウが開きました)。
SCShot_150329_0022-Installing_Tizen_2.2.1_SDK-MacOSX-1024x768
Workbenchウィンドウの構成も、Tizen SDK 2.2.1と2.3 Rev2では少し違っています。

【参考ページ】

  1. MacにJava(JDK)をインストール - Qiita
  2. Macに「Tizen SDK」をインストール | Tech Cauquet
  3. GClue blog: Tizen SDKのインストール


posted by とみやん at 18:53| Comment(0) | TrackBack(0) | モバイルOS研究 > Tizen

2015年03月22日

横浜・日吉で過ごす休日

先週から気温が上がって暖かくなり、一気に春らしくなってきました。今日は気温が18℃まで上がりすごく温かいです。急に暖かくなったので、体感的には20℃位に感じます。もはや完全に春の陽気ですね。信州も今日は温かいようですが、中信の3月の平均気温は10℃前後で今月一杯は肌寒い日々が続きます。信州と比べるのは間違いだと思いますが、こちらの春は暖かくて過ごし易いです。一体何処の話をしているのかと思われそうですが、私はいま横浜の日吉という所に滞在しています。横浜は海に近く、春や夏に南から温かい海風が吹くとかなり気温が上がります。今日の風は強くありませんが、その海風が緩やかに吹いています。

去年の9月から神奈川県内の会社で派遣常駐の組込みLinux関連の仕事を続けていましたが、先月末にその仕事がやっと終わりました。この仕事は本当にきつくて厳しかったです。去年10月から今年2月まで5ヶ月連続で労働時間が200Hを超えていることが、それを表しています。毎日夜10時まで残業、毎週土曜日は休日出勤、さらに休日まで滞在先の部屋で仕事の作業をやっていました。ソフトウェアの主要な部分を私一人で開発することになり、ほぼ全責任を背負わさせてしまったため、こういう働き方でしかこなすことができませんでした。作業ボリュームとして2〜3人分の仕事を一人でやっているような感じで、アシスタントも相談相手もおらず孤立無援だったこともストレスに拍車をかけていました。私の年齢でこれだけハードに働くと、身体が悲鳴を上げてしまいます。去年末に体調を崩してしまい、それでも仕事を続けざるをえない状況に陥り本当に苦しい日々が続きました。何とか開発業務を完遂できましたが、いまも体調が完全には回復していません。年齢的に身体の回復力が低下しているので、自然に回復するのに時間がかかっているのだと思います。大きなストレスを抱えたまま仕事を続けていたので、もしかすると「燃え尽き症候群」に陥っているのかもしれません。新しい事へ挑戦する意欲がぜんぜん湧いて来なくて困っています。体力と気力の両方が回復するに、少し時間がかかりそうです。

さて、たまには良いかなぁと思って、近況報告の記事でも書きます。じつは、去年の9月から私はずっと日吉に滞在していました。あまりに本業の仕事が多忙すぎて、プライベートな時間がまったく取れなかったので、日吉には滞在先の部屋で寝るために帰っているだけでした。日吉の街の印象とかを書きたいと思っていたのですが、なかなか書けずにいました。たまの休日に近くの定食屋やレストランなどで食事をするくらいだったので、記事を書けるほどのネタも持っていません。やっと仕事も片付いて束の間のモラトリアム時間ができたので、最近は日吉の街をブラブラと散策して過ごしたりしています。
IMG_20150322_162413-Yokohama_Hiyoshi-Town_Scene.jpg
IMG_20150322_162658-Yokohama_Hiyoshi-Town_Scene.jpg
IMG_20150322_163621-Yokohama_Hiyoshi-Town_Scene.jpg
IMG_20150322_164415-Yokohama_Hiyoshi-Town_Scene.jpg
IMG_20150322_165026-Yokohama_Hiyoshi-Town_Scene.jpg
IMG_20150322_165902-Yokohama_Hiyoshi-Town_Scene.jpg
日吉と言えば、慶応義塾大学の日吉キャンパスが在るので有名です。と言うか、日吉にはほぼそれしかないと言っても良いでしょう。街中は学生だらけで、私のような年配者にとってはすごく居心地が悪いです。平日の日中は若者限定の街と言っても良いくらい、駅周辺では学生しか見かけません。そして、金曜日の夜ともなれば、駅周辺の飲み屋は学生達で溢れかえり、飲んで騒いでいる声があちらこちらから聞こえます。慶応大学の学生は裕福な家庭の子供ばかりなので、社会マナーが高く悪ふざけや馬鹿騒ぎはしませんが、金曜日の夜は特に若者特有の活気が街全体に漂っている感じがします。日吉の街の規模は小さく、駅から徒歩10分圏内にしか店がありません。駅周辺は若者向けの店ばかりで、大きなスーパーもないので、家族持ちにとって日吉は住み心地の良い街だとは思えません。その所為か、東横線沿線の近隣の街と比較すると、日吉より武蔵小杉や元住吉の方が人気が高いらしいです。

裕福層が多く住んでいるからか、東急東横線沿線は東京でも物価が高い地区として有名です。駅ビルの中に小さめの東急ストアが在るのですが、食品の値段が全体的に高くて、私はこのスーバーをまったく利用していません。駅から15分位離れた場所にアピタという大型スーパーが在り、こちらの方が食品の値段が安いので、休日にこちらでまとめ買いをしています。滞在場所のすぐ近くにピアゴというコンビニ規模のミニスーバーが在って、こちらの店も良く利用しています。都会の街なので一通りの種類の店はすべて揃っていて不便さは感じませんが、商品を買うときに店を選べるほどではありません。全体的にイマイチ感が強い街というのが日吉の印象です。マイナス点ばかり書きましたが、裕福層が多く住んでおり優等生的な学生しかいない街なので、全体的に上品な雰囲気が漂っているのは日吉の良い所だと思います。

私は日吉に7ヶ月滞在していますが、この街に住んでみたいとはまったく思いませんでした。たまたまリーズナブルなマンスリー物件を見つけたから滞在していただけなので、日吉の街に特別な思い入れも感じません。もう少しでのその日吉からも離れるので、短い期間とはいえ人生の一時期を過ごした場所の記録を残すために本記事を書いています。

色々と書くことがあるかなぁと思っていたのですが、これ以上のネタを思いつきません。日吉はそれくらい小さな街です。まったく内容のない記事になってしまいましたが、これで終わりにします。
posted by とみやん at 14:38| Comment(0) | TrackBack(0) | 日記

2015年03月19日

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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


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

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

HWMON_MODULES="coretemp"

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


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

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

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

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

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

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

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


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

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

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

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

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

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

【2015/03/23 追記】

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

module_autoload_i2c-dev = "i2c-dev"

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

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

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


【参考ページ】

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

2015年03月17日

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Section "Files"
EndSection

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

【2015/03/21 追記】

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

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

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

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

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

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