UPDATE: 出してたPRがMergeされました。やったね！
Raspberry Pi、言わずとも皆さんご存知ですね。
Raspbian、言わずとも皆さんご存知ですね。
今ちょうど仕事で RPi-Distro/pi-gen ていうソフトを使ったRaspbianのカスタマイズをやってて、出力したOSイメージを毎度SDに焼くのはかったるいということでQEMUでエミュレートすることにしました。まあ細かく言えば環境が少々変わっちゃうんですが、実機でなくても確かめられる範囲はこれで検証できます。
Raspbian内蔵のカーネルでQEMUが仮想化してくれるかというとそういうわけではなく、QEMU用にカスタマイズされたカーネルを使います。これはGitHubにいる優しいお兄さんのおかげで簡単に手に入ります。それが dhruvvyas90/qemu-rpi-kernel です。
ところがどっこい、ここにあるRaspbian Buster向けのKernel (Linux 4.19) だとQEMUにXorgはおろかfbcon（RasPiのロゴとカーネルログがずらずら流れるやつ）すら出ません。ちょっと探ってみると原因もすぐ見つかりPR（Merge済み）も出せましたが、Device Tree 〜 Kernelのグラフィック系の前提知識がないとちょっと難しそうな印象でした。
結果的に、ブログでまとめるとちょうどよさそうな重さになったので、このトラブルシューティング事例を題材にして、組み込みLinuxの片鱗やDRM/KMS（簡単に言うとLinux Kernelのグラフィック周りのスタック）がどのように構成されているかちょっと学んでみましょう。学びを重視したいので、文章は「問題を深掘っていった流れ」で進めます。
環境
- Host
- Rootfs: Debian 10 Buster
- Linux: 4.19.0
- QEMU: 3.1.0
- Guest
- Rootfs: 2020-02-13-raspbian-buster.img
- Linux: qemu-rpi-kernel/kernel-qemu-4.19.50-buster
- Device Tree: qemu-rpi-kernel/versatile-pb.dtb（修正前）
まず動かしてみる
QEMUを入れます。
$ sudo apt install qemu-system-arm
qemu-rpi-kernelに書いてあるように、Raspbianとリポジトリをダウンロードします。
$ git clone git@github.com:dhruvvyas90/qemu-rpi-kernel.git $ wget http://ftp.jaist.ac.jp/pub/raspberrypi/raspbian/images/raspbian-2020-02-14/2020-02-13-raspbian-buster.zip $ unzip 2020-02-13-raspbian-buster.zip
ひとまず書いてあるとおりに起動してみます。Shellも欲しいので追加で -serial stdio を入れます。
$ qemu-system-arm \ -M versatilepb \ -cpu arm1176 \ -m 256 \ -hda 2020-02-13-raspbian-buster.img \ -net user,hostfwd=tcp::5022-:22 \ -dtb ./qemu-rpi-kernel/versatile-pb.dtb \ -kernel ./qemu-rpi-kernel/kernel-qemu-4.19.50-buster \ -append 'root=/dev/sda2 panic=1' \ -no-reboot \ -serial stdio
するとウインドウには "Guest has not initialized the display (yet)." としか出ません。 "yet" とあるのでちょっと待ってみても変化なし。
Shellを見ると起動自体はできているようです。
Raspbian GNU/Linux 10 raspberrypi ttyAMA0 raspberrypi login:
Xのログを読む
GUIが出ないということは、Xorgのログにヒントがないか見ることが多いです。見てみましょう。
pi@raspberrypi:~$ cat /var/log/Xorg.0.log | grep EE
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[ 103.384] (EE) open /dev/fb0: No such file or directory
[ 103.390] (EE) open /dev/fb0: No such file or directory
[ 103.390] (EE) No devices detected.
[ 103.390] (EE)
[ 103.391] (EE) no screens found(EE)
...
おや、 /dev/fb0 がないと言っています。Xorgが絵を描く先であるFramebufferは、デバイスファイル /dev/fb0 として露出します。
Xorgも /dev/fb0 もしくはDRM（後述）を叩くおあつらえの共有ライブラリがなければお手上げです。これ以上の情報は得られません。
Device Tree を見てあたりをつける
fb0 がないというのは、グラフィック系のドライバが初期化に失敗していることを意味します。ここからKernelを見に行きたい…とその前に、Device Treeを見ておきましょう。Treeをヒントに、SoCのグラフィックドライバに何が使われているかを見つけ出しておく必要があるからです。
Device Treeというのは、超短く言うと「ここのアドレスにこういうコンポーネントがいるよ・コンポーネントの動作設定もついでに書けるよ・コンポーネント間の関係性も記述できるよ」という「システムの地図」みたいなやつです。各コンポーネントに対応するドライバがカーネル内で叩き起こされて、記述された動作設定を元にドライバが初期化を行います。
x86だと使われることがなくいまいちカーネルの人々も話題にしている印象がないものの、ARMのようなメモリマップドIOのアーキテクチャでは広く使われています。
かつてはどのアーキテクチャでも、ボード毎に初期化コードをCで丹精込めて書いていました。Mainline Linuxでいうと /arch/arm/mach-* なんかは全部そうです。ところが、ARMアーキテクチャの多種多様なボードの多種多様な初期化コードを世界中の人が送りつけまくった結果、LinusがブチギレてDevice Treeによるハード構造の表現が一般的になりました。Device Treeの元となったOpen FirmwareはLinuxとは別に1999年から存在していて、Open Firmwareに参画していたIBMの影響か /arch/powerpc 内でのみ使われていたものが、2007年5月に汎用化されました。このあたりの歴史は英語版Wikipediaが詳しいです。
少し脱線してしまいました。では、Device Treeを実際に読んで、 fb0 を喋るはずだった「画面出力を担っているコンポーネントの名前」を見つけに行きましょう。
Device Tree Compilerを入れます。
$ sudo apt install device-tree-compiler
qemu-rpi-kernel に同梱されている versatile-pb.dtb をデコンパイルします。ちなみにversatile pbはVersatile Platform Baseboardの略で、ARM公式の開発ボードのことを指しています。開発ボードのSoCをエミュレートしているということですね。
$ dtc -I dtb -O dts versatile-pb.dtb > versatile-pb.dts $ editor versatile-pb.dts
するとJSONっぽいようでそんなこともない、構造化されたデータが見えてきます。Gistに全文上げたので見てみてください。
わかりやすい部分をピックアップすると、カーネルのログが出るstdoutのパスとか…
I2Cコントローラーが 0x10002000 にあり、それにRTC（リアルタイムクロック）DS1338が接続されていて、さらにアドレスが 0x68 であるとわかるとか…
AMBAバス（多分AHB）にUARTコントローラーが接続されているとか…
なかなか興味深いですね。ここでお気づきの方もいるかもしれませんが、各ノードの compatible プロパティに設定されている文字列が、「このコンポーネントを制御するドライバ」を判別するヒントになります。実際にカーネル内でドライバを見つけるときもこの文字列がいろいろに使われます。
では画面出力を担当するコンポーネントはどれでしょうか。答えは /amba/display@10120000 です。
どうしてわかるかというと、 display というそれっぽいノード名に加えて、Mainline Linux内で pl110 で文字列検索すると /drivers/gpu/drm/pl111/*.c がぞろぞろ出てくるからですね。 /drivers/gpu/ 以下はすべてグラフィック系ドライバです。
dmesgを見る
デバイスドライバが /drivers/gpu/drm/pl111 であるとわかったので、dmesgにエラーが出ていないかチェックしましょう。
pi@raspberrypi:~$ dmesg | grep 'pl11.' [ 0.293567] drm-clcd-pl111 dev:20: no max memory bandwidth specified, assume unlimited [ 0.294505] drm-clcd-pl111 dev:20: set up callbacks for Versatile PL110 [ 0.295974] drm-clcd-pl111 dev:20: No bridge, exiting
最後の行が少し怪しいですね。 ドライバの初期化がうまくいったのに exiting と出すことはまずないので、失敗してそうなニオイがします。
該当箇所を探してみましょう。
$ ag "No bridge, exiting" drivers/gpu/drm/pl111/pl111_drv.c 166: dev_err(dev->dev, "No bridge, exiting\n");
前後を取り出すと（GitHubはこちら）
165 } else {
166 dev_err(dev->dev, "No bridge, exiting\n");
167 return -ENODEV;
168 }
やはりそうですね。 dev_err を呼んでエラーメッセージとして出した後、 -ENODEV を返しています。
真因に迫る
かなり怪しいポイントには近付いた気がするものの、次は "No bridge, exiting" の意味を理解して直してやらねばなりません。
ところで、qemu-rpi-kernelで配っているカーネルのうち、 Raspbian Stretch用の kernel-qemu-4.14.79-stretch だと画面は普通に表示されます。この 4.14 から 4.19 の間に、何かヒントがありそうです。
例の "No bridge, exiting" の行を git blame してみます。
4.14〜4.19の間である4.17の時代にマージされた、このコミットが出てきました。
if (panel) {
bridge = drm_panel_bridge_add(panel,
DRM_MODE_CONNECTOR_Unknown);
if (IS_ERR(bridge)) {
ret = PTR_ERR(bridge);
goto out_config;
}
- /*
- * TODO: when we are using a different bridge than a panel
- * (such as a dumb VGA connector) we need to devise a different
- * method to get the connector out of the bridge.
- */
+ } else if (bridge) {
+ dev_info(dev->dev, "Using non-panel bridge\n");
+ } else {
+ dev_err(dev->dev, "No bridge, exiting\n");
+ return -ENODEV;
+ }
+
+ priv->bridge = bridge;
+ if (panel) {
+ priv->panel = panel;
+ priv->connector = panel->connector;
}
上の方で panel という変数がNULLかどうかチェックしています。このコミット以前は、仮に panel がNULLだったとしてもそのまま放って初期化を継続していたのが、このコミット以降は諦めるようになりました。これがStretch (4.14)とBuster (4.19)の差分の正体であり、真の原因となります。
ここをもとに戻せば動きそうですが、あまり気持ちのいい対処方法ではありません。より正統派の対処として、ここはドライバが所望している panel もしくは bridge なるものを用意して渡してやろうということになります。
DRM/KMSの構造
ここから先はDRMの紹介なくしては話せないので、DRMの紹介をしましょう。
DRM (Direct Rendering Manager)とは、GPUなどグラフィック系デバイスとUserspaceがやりとりするためのLinuxのサブシステムです。平たく言うと、GPUとのやりとりを抽象化していい感じにしてくれるやつです。
KMS (Kernel Mode Setting)とは、画面の表示モードの設定をカーネル内で行う仕組みの名称です。DRMはもともとGPUの複数プログラムによる共同利用などを意図した仕組みですが、3Dとか高度なグラフィックを使わないパイプライン（メモリ上のFramebufferをちょっと変換しつつDMAで液晶に飛ばすだけのコンポーネントとか）においては画面の初期化と表示モードの設定が主たる実装内容になります。そのためか、DRM/KMSとニコイチで呼ばれることが多くなっています。
DRMは、ソフトが絵が描くメモリ上の場所からその絵が表示されるLCDなどまでのパイプラインを機能ごとに区別して管理しています。図にすると以下のような感じ。
（引用元: Kernel Mode Setting (KMS) — The Linux Kernel documentation）
Framebufferは、ソフトウェアが絵を描く先です。Planeは、Framebufferやその他のアセット・マウスポインタなど描画される対象を示します（説明が難しい）。CRTCはCRT Controllerの略で、もうCRTなんて使われてないですが、解像度やVblank（GPUが絵を描けるタイミング）の設定を司るコントローラを指します。Encoderはデジタルなデータをアナログの信号に変調したりする部分を指します。Connectorは名前の通りモニタを接続するコネクタを指します。
組み込みLinuxにおいては、Device Treeが、このパイプラインの記述を担うことが多いです。GPUが描いた絵の出力先をノードとして記述しておくと、ドライバはこの情報を参考にして画面出力の設定を行います。この「出力先」が前節で登場した "Panel" や先ほど説明した "Encoder" になるわけです。ちなみに "Encoder" と "Panel/Connector" の間に置いて互いを接続する部分もOptionalで利用でき、 "Bridge" と呼ばれます。
今の時点では、解像度の設定などを司るCRTCは実装上存在する扱いになっています。一方で、Encoder、Connectorはまだありません。これらに相当する部分をDevice Treeに書いてやれば良さそうということになります。
ではRasPi on QEMUの場合は？
まだ現時点でわかっていないのが、デバイスドライバである pl111 がDevice Treeにはたしてどういう記述を期待しているかです。これはDocumentationを読むとわかります。
40行目の "Required sub-nodes" で書かれている ports は、どういうLCDやBridgeやConnectorがどう接続されているか書く場所です。文字通り "Required" な値です。これが書かれていないから、先述のif-elseで弾かれてしまったというわけです。
port の記述例についても同じテキストに書いてあります。黄色の部分が追記するべき場所です。
この例では、Panelを定義して直接接続しています。 panel-dpi はMIPI DSIという規格で接続されたPanelを表し、これもまたドライバが存在します。
なお、画面サイズとタイミング情報もあるためこれをコピーすれば勝手に上手く行ってくれるかなと思ったのですが、どういうわけかうまくいきませんでした。panel-dpi はMIPI DSIのドライバなので、ちゃんと物理的に接続して初期化シーケンスを踏まないと認識してくれないのかもしれません。
そこで、別のボードの例を参考にして、あたかもVGAが接続されているかのような記述を試しました。その結果のdiffが以下の通りです。
--- versatile-pb.dts 2020-04-24 21:11:25.649481714 +0900 +++ versatile-pb-buster.dts 2020-04-24 21:12:04.381243808 +0900 @@ -31,6 +31,38 @@ phandle = < 0x02 >; }; + bridge { + compatible = "dumb-vga-dac"; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + vga_bridge_in: endpoint { + remote-endpoint = <&clcd_pads>; + }; + }; + port@1 { + reg = <1>; + vga_bridge_out: endpoint { + remote-endpoint = <&vga_con_in>; + }; + }; + }; + }; + + vga { + compatible = "vga-connector"; + + port { + vga_con_in: endpoint { + remote-endpoint = <&vga_bridge_out>; + }; + }; + }; + core-module@10000000 { compatible = "arm,core-module-versatile\0syscon\0simple-mfd"; reg = < 0x10000000 0x200 >; @@ -241,7 +273,14 @@ reg = < 0x10120000 0x1000 >; interrupts = < 0x10 >; clocks = < 0x04 0x03 >; - clock-names = "clcd\0apb_pclk"; + clock-names = "clcdclk\0apb_pclk"; + + port { + clcd_pads: endpoint { + remote-endpoint = <&vga_bridge_in>; + arm,pl11x,tft-r0g0b0-pads = <0 8 16>; + }; + }; }; sctl@101e0000 {
まずpl110の方（下の方のdiff）で、件の port を追加し、その中のendpointとして上の方に書いた dumb-vga-dac をつないでやります。
dumb-vga-dac （ドキュメントはこちら）はRGBを入力してVGAの信号として出すEncoder的なBridgeで、 port@0 にGPUからの出力、 port@1 にVGAコネクタをつなぎます。
そして最後に dumb-vga-dac の出力を vga-connector を接続してやれば、DRM/KMSで求められる構造はすべて定義できたことになります。
ちなみに、 clock-names のdiffは、pl110に入力されるクロックの名前が clcdclk でないとエラーが出たので修正したものです。
動作確認
テキストで書いたDevice Tree (dts) をバイナリ形式 (dtb) にコンパイルします。
$ dtc -I dts -O dtb versatile-pb-buster.dts > versatile-pb-buster.dtb
QEMUに読ませます。
$ qemu-system-arm \ -M versatilepb \ -cpu arm1176 \ -m 256 \ -hda 2020-02-13-raspbian-buster.img \ -net user,hostfwd=tcp::5022-:22 \ -dtb ./qemu-rpi-kernel/versatile-pb-buster.dtb \ -kernel ./qemu-rpi-kernel/kernel-qemu-4.19.50-buster \ -append 'root=/dev/sda2 panic=1' \ -no-reboot \ -serial stdio
お！！！
やったー！！！
バージョンとかも見ときましょう。
うんうん、ちゃんと4.19ですね。XGA (1024x768) なのは、 dumb-vga-dac にハードコードされた解像度がXGAだからです。普通ならI²CでディスプレイからEDIDを得ますが、それがないのでフォールバックしています。
まとめ
なんか見る範囲が広くてあまりついてこれなかったという人も多いかもしれません。実際のところLinuxはドライバとか触るだけでかなりの情報量なので最初は大変だと思います。ところがDocumentationの探し方やコードがだいたいどこにあるかがわかってくると触りやすくなってきます。
ぜひ組み込みLinuxのグラフィック周りのような、ハードとソフトの境目を渡り歩くような面白い世界をお手元のRaspberry Piで体感してみてください。もし機会があれば！
