BSD小僧の日記

ZBOX nano VD01にはBluetoothが装備されているらしく、せっかくだから使ってみましょうと思い立ちました。

The NetBSD Guide Chapter 21 Bluetooth on NetBSDという文書を発見。

ほー、これは助かる。と思いつつ読みはじめて、まずデバイスを認識してなきゃ話になりませんなー、ということでubtがあるのか確認です。

...

ubtはありませんでした。なんだかな。うーんと思いつつbtで検索すると次のようなメッセージが。

aubtfwl0 at uhub3 port 1
aubtfwl0: ath3k-1.fw open fail 2

man aubtfwlしても何も出てきません。とはいえ、これまで見たこともないデバイス名ですし、なんだか気になるので調べてみるとどうやらAtherosのBluetoothのためのドライバのようです。おぉ、なんとかとっかかりを見つけることができたようです。

しかし、Atherosといえば無線LANとばかり思っていましたが、いわれてみればBluetoothも同じ無線ですからAtherosの製品があったとしても不思議ではないですね。

さて、どうやらaubtfwlはath3k-1.fwをファームウェアとして必要としているらしく、そのopenに失敗しているようです。

fail 2の2って何かといえばENOENTですからNo such file or directoryということのようです。確かにath3k-1.fwなんてファイルはシステムのどこにも存在しません。

じゃぁ、ath3k-1.fwはどこにあるのさ、と思って探してみるとhttp://git.kernel.org/?p=linux/kernel/git/firmware/linux-firmware.gitにあるようです。ここにあるLICENCE.atheros_firmwareを見て、今回の用途においては問題がないと判断したので、ここのath3k-1.fwを使わせてもらうことにしました。

では、どこにファームウェアを置けば良いのでしょう。
ファームウェアを開いている firmware_open -> firmware_path_first -> firmware_paths -> FIRMWARE_PATHS と追っかけていくと、

     75 #define	FIRMWARE_PATHS		\
     76 	"/libdata/firmware:/usr/libdata/firmware:/usr/pkg/libdata/firmware:/usr/pkg/libdata"
     77 #endif

という記述にたどり着きました。どうやらsysctlのhw.firmware.pathで見ればわかったようですね。しらんがな。

じゃぁ、/libdata/firmwareに置くことにしましょう。といって、どう置けば良いのでしょう。先のfirmware_path_firstからfirmware_path_nextに読み進めると、drvnameつまりドライバ名をディレクトリとしてファームウェアファイルを読み込むわけです。

今回だとdrvnameはaubtfwlですから/libdata/firmware/aubtfwl/ath3k-1.fwというファイルの置き方をすれば良いということになります。

あれ?

あいかわらず、

aubtfwl0: ath3k-1.fw open fail 2

のようです。

おっかしーな、と思ってもう一度aubtfwl.cを見てみると、

    104 	error = firmware_open("ubt", "ath3k-1.fw", &fwh); /* XXX revisit name */

なんと、ubtって書いてあるじゃないですか!!! 直接書くなよ。

あらためて、/libdata/firmware/ubt/ath3k-1.fwで起動してみると、

aubtfwl0 at uhub3 port 1
aubtfwl0: beginning firmware load
aubtfwl0: firmware load complete
aubtfwl0: detached
aubtfwl0: at uhub3 port 1 (addr 2) disconnected
aubtfwl0 at uhub3 port 1
aubtfwl0: beginning firmware load
aubtfwl0: firmware load complete
aubtfwl0: detached
aubtfwl0: at uhub3 port 1 (addr 2) disconnected
ubt0 at uhub3 port 1
ubt0: vendor 0x0cf3 product 0x3005, rev 1.10/0.01, addr 2

何度かaubtfwlがattachとdetachを繰り返して、見事ubt0が生えてきたのでありました。

やっとスタートラインに立てたようです。まずは、ここまで。

昨日、OSC2012 Tokyo springにてkozosのブースで作者の坂井さんとお話させていただきました。

リンカ・ローダ実践開発テクニックを2FのCQ出版社のブースで購入したので、サインをもらったりしました。例の魚の絵を描いてもらってうれしい。

それはそれとして、例のOS自作本を読み進める中でつまづくのは7章、8章と1章なのだそうです。7章、8章は内容的な難しさで1章は物理的なトラブルに起因する難しさだそうです。

つまり、シリアルをつかったボードとの通信ということですね。

坂井さんも秋月のUSBシリアルを貸し出したり、あれこれ工夫されているということですが、いざ自身のUSBシリアルでうまくいかなかったりと、作者すら巻き込んだ状態で困ったチャンということのようです。坂井さんの場合だとボードがヘタっているのかも疑わなければならないそうですから大変です。

このあたりのトラブルに巻き込まれて1章で挫折している人がたくさんいるのではないかとお話されていました。

ということで、例に漏れず、シリアル経由でボードに書き込めないトラブルに遭遇していたので、すこしその辺を記録しておきます。

まず、そもそもNetBSDで動かそうというところからして、想定環境とは違うのですが、まぁ、そこもふくめて楽しむのがホビーというものだろうと思いまして、あえてNetBSDで挑戦です。

自作本ではh8writeを使っていますが、イマドキはWebページも合わせて読み進めるのが常識でして、その辺の情報を見るかぎり、h8writeがだめだったらkz_h8writeを試してみてねという話になっていて、実装の確かさからkz_h8writeでがんばろうとしたようです。

したようです、と書いたのは理由があって、ずいぶん昔にはkz_h8writeでうまくいっていたのですが、長いブランクのあと試してみると、なぜかうまくいかないという事象にぶつかったからなのです。

で、技術がなければ根性で、をモットーにfprintfデバッグをしていたところ、どうやらシリアルポートを開いているところで止まっているみたいだなということがわかったので、man openして、待ってるんだから待たなきゃいいじゃん、ということでO_NONBLOCKを加え、NetBSDでは意味ないよとかかれているO_NOCTTYを削ってみると、うまく書き込みができるようになりました。

--- serial_linux.c.orig	2012-01-02 06:06:36.000000000 +0000
+++ serial_linux.c	2012-03-18 09:21:24.000000000 +0000
@@ -89,7 +89,7 @@
      * ポートを開く.
      */
     strcpy(s->devfile, devfile);
-    s->fd = open(devfile, O_RDWR | O_NOCTTY);
+    s->fd = open(devfile, O_RDWR | O_NONBLOCK);
     if (s->fd < 0) {
         free(s);
         return NULL;

という修正をしたのがkz_h8write 0.0.3です。

で、さっきWebをみるとgitリポジトリが公開されていることを発見しました。いまどきはgitなんですねぇ。

最新のserial_linux.cソースを見るとopenの引数にO_RDWR, O_NOCTTY, O_NDELAYが与えられています。

0.0.3には存在しなかったO_NDELAYがどうやら先ほどのO_NONBLOCKに相当するもののようですね。lxrで検索してちょろっと見るかぎり、x86ではO_NDELAYはO_NONBLOCKはまったく同じ定義、HP-UXでは別物として扱っていて、alphaはO_NONBLOCKしかなくて(なんでだろ)、sparcでも微妙に扱いを変えているみたいです。

ちなみにPOSIX.1-2008のopenをみるとO_NONBLOCKしか見当たらないので、ポータビリティの観点とx86の実装の観点からもO_NONBLOCKのほうが無難かなと思ったりする次第。

NetBSDではO_NOCTTYは無視されてO_NONBLOCKが有効に動くので上のようなパッチもいらないですね。