http://www.libnfc.org/documentation/introduction
Open NFCを見ていこう！と思ったが、libnfcというのもある。
見た感じでは、PN532なんかは対応しているようだ。
libnfcにはLLCPがないのだが、それを使った別のプロジェクトにnfc-toolsというものがあった。
http://code.google.com/p/nfc-tools/source/browse/trunk/?r=795#trunk%2Flibnfc-llcp
ここにLLCPの実装っぽいものがある。
が、正式な資料がないため、位置づけがよくわからん。
最終コミットは2011/5/12。
うーん。
うーーーーん・・・・・
Open NFCは、今の最新版が4.3.1 r0(11634)で、これは2011/10/10リリースだ。
エディションが5つある。
詳細は、各エディションのリリースノートを見てくれ、とのこと。
うーむ。
この中で、とりあえずわからない単語が出てきた。
MicroRead。
これは、Inside Secure社のNFC商品だ。
なんでこれだけ別になっているかというと、Inside Secure社がOpen NFCのスポンサーだからだ。
Open NFCのベースを作成をして、後からオープンソースにしたのか、先にOpen NFCがあってスポンサーになったのかはわからないが、今風のやり方だな。
SONYもRC-S620/Sと一緒にこういうのをやってくれると国内で盛り上げられていいのだが。
Arduinoのサンプルはあったけど、Open NFCレベルのものはオープンで作ってくれなさそうに思う。
それなら買ってくれ、という戦略だから仕方ないのだが、そうなるとユーザとしては・・・。
いかんいかん、こういうのは気にしたら時間が足りないのだ。
あるものを使っていこう。
今回はやらないのだが、Android Editionがどういう位置にあるのか読んだところ、2.3.5でビルドしているそうだ。
そしてそれはプラットフォームのビルドから行う必要がある。
Android Add-on Editionというものもあったが、これはAndroid SDKでビルドしたりAVDを起動したりさせるためのもので、Android Editionとセットになると考えていいんじゃなかろうか。
アプリのAPIは、Open NFC用というわけではなく、通常のAndroid APIでよいように見える。
わざわざAdd-on Editionを提供しているのは、エミュレータからでもMicroReadのようなハードウェアを実際に接続して動作させることができるようにしているからのようである。
実機で動作確認できるのは、ポイントが高いよな。
で、残りのEditionだ。
NFC Simulatorってのが気になるが、これはオープンソースではない。
Win32専用ってのは、そういうことなのだ。
仮想的なNFCデバイスを作り、NFCソフトウェアスタックをエミュレーションできるようなのだ。
どうやってやるのかと思ったが、そこにConnection Centerが出てくる。
これもWin32専用。
TCP/IPでデバイス間を接続するイメージらしい。
Linux Editionではこのあたりのツールが動作しないけど、対抗機としてWin32のマシンを用意できればよいようだ。
おっと、ここで注意が。
NFC Simulatorは、タグとしてType1, 2, 4をサポートしている。
つまり・・・FeliCaは対象外なのだ。
まあ、しょうがないかな。
そんなわけで、以降はLinux Editionを見ていく予定だ。
なんだこのタイトルは？
まあいいや・・・。
LLCP-1.1ドキュメントをちょっとだけ読んでいたのだが、自分で実装するのはめんどくさそうだ。
めんどくさいというか、ちゃんと動くものを作るまでにえらく時間がかかるだろう。
あんまりこの辺には興味がないので、さっさと終わらせてしまいたいのだが・・・。
ならば、実装されているものを探せばいいじゃないか、ということにようやく思い至った。
ネットで検索・・・。
出てきたのは、Open NFC。
そういえば、以前も少しだけ見て、やめたことがあったな。
再び見るときがやってきたようだ。
Welcomeメッセージに、こんなことが書いてある。
Open NFC TMはNFCコントローラチップセットの上に載るNFC機能を実装したソフトウェアスタックである。
主な機能：
つまりまあ、NFC Forumでドキュメントになっているようなことはすべて実装されているってことのようだ。
では、これからしばらくは、Open NFCのことを調べてみようかね。
仕方ないので、LLC手順にどういうものがあるのかだけ見ていこう。
詳細を見る気力はない。
この３つが基本っぽい。
"Normal Operation"では、5.5～5.9のことができるようだ。
InitiatorかTargetかでちょっと違いそうなことが書いてある(読んでないけど)。
この２つは、UDPとTCPみたいな位置づけに見える。
この３つは、なんとなく別物って雰囲気が漂っている。
Service Discoveryは新顔で、たぶんNPPと関わりが深そうだ。
いつか読まねば。
ネタを小出しにしているように見えるだろうが、書きながら調べているだけだ。
そして、調べる時間があったら早く寝たいというところ。
まあ、しばしこんなペースでしかできませんな。
PAX, (AGF), (UI), CONNECT, CC, (DM), (FRMR), (I), SNL
上記が何かというと、LLCで使われるPDUのうち「Parameter」という部分を持っているものだ。
上以外のものは、データ部がない。
括弧で囲んだものは、データ部はあるが「Parameter」ではない。
「Parameter」でないものは、それぞれの説明がある。
そして「Parameter」の説明をしているのが「4.4 LLC Parameter Format」である。
いろいろと把握するやり方はあると思う。
人それぞれだろう。
私の場合、データの単位がわかったら(今回は「PDU」という単位)、次はそのデータをどうやりとりするかというシーケンスを確認したいところだ。
PDUの詳細を見てからシーケンスを確認する、というやり方もあるだろうけど、「こういうやりとりをするからこのPDUがあるんだ」というような把握をしていく方が私にはあっているようだ。
ならば次に読むのは「5 LLC Procedures」だ、と思ったが・・・図がない。
手順なら、シーケンス図がほしいじゃないか・・・。
NFC ForumのLLCP-1.1。
なかなか読む気になれないが、読み始めなくては進まん。
とっかかり易いところから読むか。
そんなわけで、4.1を見た。
4.1 LLC PDU Format
ここには、PDUのパケットフォーマットの構成が書かれている。
LLCPヘッダとLLCPペイロードから成る。
LLCPヘッダは、DSAP+PTYPE+SSAP+Sequence。
Sequenceはあるときとないときがある。あるときは、1byte。
それ以外の部分は、それぞれ6bit、4bit、6bitで16bit。
つまり、2byteか3byteあるってことだ。
LLCPペイロードは、バイト単位。
SAPはService Access Pointの略。
送信先(Destination)と送信元(Source)だ。
6bitなので、0x00～0x3fまで表すことができる。
このうち、0x00～0x0Fまでは「Well-Known Service Access Point」と呼ばれる。
0x00は使用禁止(?)、0x01はSDP用、残りはこちら。
http://www.nfc-forum.org/specs/nfc_forum_assigned_numbers_register
例を見らんとわからんなぁ。
私のNFC-DEPに持つイメージは、こんな感じだ。
イメージを図にするとしても、解釈したい内容によって図の作りが変わってくる。
今回は、アプリからNFC-DEPで送信するときはこういう風に扱われるんですよ、という図にしようとして、挫折した感じだ。
DEPは、R/W同士で行うものだろう。
だからPCDが向かい合っている。
PCD間は、もちろんNFC-DEPでデータ交換している。
ではその上に何が来るかというと、LLCPだ。
物理レベルの転送がDEPなら、論理レベルの転送はLLCPと言えようか。
アプリから100KBのデータを送信してくれ、という要求が来たとき、DEPで転送できるサイズに小分けにしてくれるのだ。
それだけではない。
自分が持つ転送能力や受信能力をお互いが交換し合い、能力を超えないようにうまいことやるのだ。
ちなみに、PCDにアクセスするためのプロトコルというのは、標準があるわけではない。
なのでこの部分は、デバイス依存ということになる。
RC-S956の場合、NFC-DEP仕様の結構な部分をデバイスが吸収してくれてたので、作るのが楽だった。
と思う。
なぜ「思う」なのかというと、送信も受信も自分で作ったので、正しくNFC-DEPが動いているかわからないのだ。
単に、送信したデータが受信できたから動いたんだろうと思っているレベル。
とはいえ、国内で簡単にDEPができる端末ってないんだよなあ。
android.kernel.gitにアクセスできなくなって久しい。
定期的に確認しているのだが、だめだった。
が、今日やってみると、なんか違うところへ飛ばされた。
わけがわからぬままにクリックすると、googlesourceなるところのgitアカウントができたようだ。
むー。
よくわからないので検索してみたところ、AOSPのドキュメントが更新されているということだった。
http://source.android.com/source/downloading.html
cygwinでやったけど、curlがうまくいかんねぇ。
そもそもcurlってなんなのかを知らないことに今さら気付いた。
電磁気学でも出てきたような気がするが、そっちでないことは確実だ。
http://www.hcn.zaq.ne.jp/___/unix/curl_manpage.html
wgetよりさらに他機能ってところなのだろうか・・・。
ブラウザからはrepoが取って来れたので、cygwin経由のhttpsがうまくさばけてないとかか。
NFC ForumのSNEP-1.0を読んだ。
わかったのは、NPPとはプロトコル構造が異なるということ。
そしてシーケンスも異なり、NPPは送りつけるだけだったのだが、SNEPはリクエストーレスポンス型になっている。
ふむ。
SNEPは再送なんかのやり方は規定がない。そこはLLCPに任せているのか(まだLLCP-1.1は読んでない)。
まあ、大ざっぱにいえば「LLCP+SNEP≒FALP」といったところだろうか。
LLCPは携帯電話などの用途に特化しているわけではないので、けっこう複雑だ。
FALPも再送なんかが難しいけど、実装するならまだFALPの方がやりやすいような気がする。
そのうち、LLCPのサブセットが出るのかもね。
Android NDEF Push Protocol Specificationを簡単に訳したが、難しい文書ではないので一読することをお勧めしよう。
以下、NPPで。
まずLLCPを使用しているというところ。
サービス名、という言葉が出てきたので”？”と思ったが、NFC ForumのLLCPドキュメント1.1からはその辺りの仕様が追加されている。
SDP、サービスの検索だ。
SNLというサービス名検索などもあるので、それを利用するのだろう。
LLCPを使うということは、必然的にNFC-DEPとなる。
つまり、ISO18092のDEP。
ということは、FeliCaでもできるってことだ。
Android 2.3.4では、NFC-DEPをサポートしていない。
新しいAPI14を見たが・・・やはりIsoDepというISO14443のDEPしかない。
うーん・・・、どう解釈するといいのだろうか。。。
AndroidのNFC資料によると、Android Beamの受信をサポートするデバイスはcom.android.npp NPPかSNEPをサポートしていなくてはならない、とある。
そして、Android2.3のAPI9からNPPはサポートしているように書かれている。
推測だけだが、IsoDepはユーザに開放して、NFC-DEPはプラットフォーム側で握っておきたい、ということなのか。
あとでソースを読んでみるか・・・。
通信は、クライアントからサーバへの方向。
それを両方のデバイスが実装することで、擬似的に双方向の通信ができるということになっている。
毎回セッションは切断するので、いいたいことだけいってから切る、ということのようだ。
まあ、PUSHっていうくらいだからな。
さて、私のところではNFC-DEPの実装はやっているが、LLCPはやってない。
実装したら、パソコンからAndroid Beamができるんだろうなぁ。
やってみたいものだが、そもそも4.0の端末(しかもNFC付き)をどうやって手に入れたものか・・・。
あ、携帯電話を買い直す、という選択肢は無しだ。
現行のMobile FeliCa ChipがNFC-DEPをサポートしているのなら、Android Beam対応のおサイフケータイってのもあり得そうだが、どうなんだろうね。
もう覚えてないなぁ。
ひどく眠たいので、違うことを書くかもしれんが許しておくれ。
Version : 1 2011-02-22
NDEF Push Protocol (NPP) はLLCPの上に載っかるシンプルなプロトコルで、用途は別デバイスへNDEFメッセージをPUSHするためのもので、client→serverの方向。
NPPをサポートするデバイスは、以下のようにあるべし。
こうすることで、NPPデバイス間で双方向のNDEF交換ができる。
(サーバ実装は必須で、クライアント実装はおまかせってこと？)
ヘッダとNDEFエントリーから構成されている。
・・・でもヘッダにNDEFエントリーが入っているから、正確にはヘッダだけか。
メジャーバージョンとマイナーバージョンがあって、今はメジャー0、マイナー1。
ヘッダの"Protocol version"はそれぞれ4bitで、0x01となる。
このバージョンではNDEFエントリーは1つだけサポートする。
このバージョンでは0x01固定。
0x01の意味は「NDEFメッセージはpassive tagを読んだかのように処理されねばならない」だ。
(ひとりごと：相手からPUSHされたのではなく、自分でPULLしにいったかのようにということ？)
サーバのサービス名は"com.android.npp"であるべし。
そしてService Discovery Protocol(SDP)で検出可能であるべし。
PUSHを受信した場合、そのNDEFエントリーは受信した順番に処理せねばならない。
(原文ではAction codeのことも書いてあるが、どっちにせよ1つしかないから同じだよな？)
サーバは、クライアントから最後のNDEFエントリーを受信後に接続を切られたら、全部受信し終わったと判断することになる。
クライアントはNDEFメッセージがあるなら、NFC-DEP接続を確立後、すぐにNPP pushを行うべし。
クライアントは、NPP pushに失敗したことを表示するために各ステージで失敗をチェックするべし。
エラーによるリトライなどはない。
クライアントは、クライアントが実装しているProtocol versionに従ったAction codeを送信するべし。
(サーバに合わせたりするんじゃないよ、ってことか)
Android NDEF Pushが気にかかり、NFC ForumのTechnical Specificationをのぞいてみた。
むむ、ファイルのバージョンがいくつか上がっている！
前回
NFCForum-TS-Activity-1.0.pdf
NFCForum-TS-DigitalProtocol-1.0.pdf
NFCForum-TS-LLCP_1.0.pdf
NFCForum-TS-NDEF_1.0.pdf
NFCForum-TS-Type-1-Tag_1.0.pdf
NFCForum-TS-Type-2-Tag_1.0.pdf
NFCForum-TS-Type-3-Tag_1.0.pdf
NFCForum-TS-Type-4-Tag_2.0.pdf
NFCForum-SmartPoster_RTD_1.0.pdf
NFCForum-TS-GenericControlRTD_1.0.pdf
NFCForum-TS-RTD_1.0.pdf
NFCForum-TS-RTD_Text_1.0.pdf
NFCForum-TS-RTD_URI_1.0.pdf
NFCForum-TS-Signature_RTD-1.0.pdf
NFCForum-TS-ConnectionHandover_1_2.pdf
今日
NFCForum-TS-Activity-1.0.pdf
NFCForum-TS-DigitalProtocol-1.0.pdf
NFCForum-TS-LLCP_1.1.pdf
NFCForum-TS-NDEF_1.0.pdf
NFCForum-TS-SNEP_1.0.pdf
NFCForum-TS-Type-1-Tag_1.1.pdf
NFCForum-TS-Type-2-Tag_1.1.pdf
NFCForum-TS-Type-3-Tag_1.1.pdf
NFCForum-TS-Type-4-Tag_2.0.pdf
NFCForum-SmartPoster_RTD_1.0.pdf
NFCForum-TS-GenericControlRTD_1.0.pdf
NFCForum-TS-RTD_1.0.pdf
NFCForum-TS-RTD_Text_1.0.pdf
NFCForum-TS-RTD_URI_1.0.pdf
NFCForum-TS-Signature_RTD-1.0.pdf
NFCForum-TS-ConnectionHandover_1_2.pdf
WinMergeで前回のものと比較すると、
そして・・・
そう、とうとうSNEPが追加されたのだ。
といっても、私も名前しか知らなかった。しかも教えてもらって知ったので、中身は知らない。
あのとき聞いたSNEPはこういう形になったんだ、という思いだけが残る。
シンプルなNDEF交換プロトコル。
PDFで20ページくらいなので、本文はすくなさそうだ。
が、見るのは週末にしよう。
甘く見て、何度痛い目にあったことか・・・。
私の予想では、Android NDEF Push(2011/02/22)が反映されてSNEP(2011/08/31)になったんじゃないか、というところだ。
まだ中身を読んでいないので、今のうちに予想しておかないとねぇ。
動かんので、いろいろやってみよう。
デフォルトのinitが実行できないが、指定したらどうなるだろう？
Failed to execute /sbin/init. Attempting defaults...
Kernel panic - not syncing: No init found. Try passing init= option to kernel.
特に違いなし。
chmod 0777 –R でフルに与えてみたが、やはりだめ。
違いは何なのだ・・・。
よくわからんので、unfs3じゃなくて、nfs-kernel-serverにしてみよう。
busyboxのオプションもちょっと変更してみるか。
ああ、/devはやっぱりもらってきておくかね。
これでどうだ！
Freeing init memory: 168K init started: BusyBox v1.19.2 (2011-10-16 20:25:27 JST) starting pid 528, tty '': '/etc/init.d/rcS' can't run '/etc/init.d/rcS': No such file or directory Please press Enter to activate this console. starting pid 529, tty '': '-/bin/sh' BusyBox v1.19.2 (2011-10-16 20:25:27 JST) built-in shell (ash) Enter 'help' for a list of built-in commands. / # |
動いた・・・。
そして、どれがよかったのかわからん・・・。
「exec prefers applets」のチェックを外したのがよかったのかなぁ。
案外、「Support utmp file」かもしれん。
unfs3はあまり関係ないように思う。PSPのは動いていたから。
週末の最後に動いたのは、よかったような残念なような。
まあ、いい方にとろう。
よかったよかった。
うまくいっていないが、まず状況を整理しよう。
Ubuntu11.04+unfs3を使用している。
名前の通り、nfsバージョン3のようである。
/etc/exports
/home/xxx/Qt/nfs 192.168.0.22(rw,no_root_squash,no_all_squash,async)
BeagleBoard C4+TI Android2.3.4カーネルに手を加えたものを使用している。
bootargs(u-bootにて指定)
mem=99M console=ttyS2,115200n8 noinitrd ip=192.168.0.22::192.168.0.1:255.255.255.0 root=/dev/nfs nfsroot=192.168.0.2:/home/xxx/Qt/nfs,nfsvers=3,nolock,rsize=1024,wsize=1024 rootfstype=nfs mpurate=600 omapfb.rotate=1 omapfb.vrfb=y vram=10M omapfb.vram=0:10M omapdss.def_disp=dvi omapfb.mode=dvi:720x480MR-16@60
AM35x/OMAP35x PSP SDK 03.00.00.00.04環境に含まれるOMAP35xのNFS向けファイル環境。
PSP SDKに入っているkernelでは、BeagleBoard用configsを指定してもビルドエラーになる。
---> とりあえずAndroidのkernelを使っているが、omapfb.vramがうまくいってない。
busyboxでつくった環境で/sbin/initが起動しない。
---> よくわからん
PSP SDKに入っているNFS向け環境だと、thttpd起動の出力以降進まない。thttpdを取り除いても進まない。
---> よくわからん
よくわからんことが多いな。
まあ、いつものことなので、あきらめずやろう。
まず、/sbin/initからだな。
PSP環境の/sbin/init.sysvinitをコピーしても同じだったので、実行ファイルのせいではなさそうだ。
かといって、NFSの設定を変えているわけではないので、残るはattributeか。
ls -lしても同じようにしか見えないのだけどなぁ。
kernelのブートは、うまくいく。
nfsもうまくいく。
exportしている/lib/modulesにkernelバージョンをあわせたものを置くとエラーが出なくなったので、nfsマウントしたファイルを読みに行っている。
nfsマウントしたファイルをアクセスしに行っているのは、たぶんユーザランド側だと思うのだけど、確信がない。
調べてみよう。
INIT: version 2.86 booting
これは、どっちが出しているのだろう？
Androidやってたときには出なかったので、たぶんユーザランドだ。
kernel起動すると最初に起動するのは、bootargsで指定したinitプロセスだ。
今回のbootargsはこうなっている。
Kernel command line: mem=99M console=ttyS2,115200n8 noinitrd ip=192.168.0.22::192.168.0.1:255.255.255.0 root=/dev/nfs nfsroot=192.168.0.2:/home/xxx/Qt/nfs,nfsvers=3,nolock,rsize=1024,wsize=1024 rootfstype=nfs mpurate=600 omapfb.rotate=1 omapfb.vrfb=y vram=10M omapfb.vram=0:10M omapdss.def_disp=dvi omapfb.mode=dvi:720x480MR-16@60
長いな・・・まあ仕方あるまい。
ともかく、initは指定していない。
指定していない場合なにが起動するかは・・・kernelのソースを見ないとわからん。
とは限らないが、そこから見ていこう。
kernelのほどほどの最初は、init/main.cにあるstart_kernel()だろう。
「ほどほど」というのは、一番最初はブートとかkernelの解凍とかになってしまうけど、そこら辺はあまり知らないからだ。
armの場合、arch/arm/kernel/head-common.Sからstart_kernelは呼ばれているようだ。
丹念に追っていけばいいのだが、めんどうなので端折ろう。
ソースを眺めていると、init_post()の中に/sbin/initなんかを起動させそうな箇所がある。
これは、start_kernel()の一番最後にあるrest_init()からkernel_init()を別スレッドとして起動することで呼び出されるようだ。
PSP環境の/を見ると、linuxrcというファイルがあるのでgrepすると、do_mounts_initrc.cの中にある。
これもたどっていくと、kernel_init()で呼び出されているが、順序としてはinit_post()より前だ。
つまり、/linuxrcを先に実行して、/sbin/initのようなinitプロセスを実行させるのだろう。
initは、
という順で探しに行き、たぶんどれか１つ実行できれば終わりだ。
なければkernel panicする。
PSP環境には/sbin/initがあるので、これが動くのだろう。
では、linuxrcと/sbin/initを見ていこう。
PSPとして入手できたファイルの中には、linuxrcもinitもバイナリしかない。
linuxrcはbusyboxで、initはinit.sysvinitだ。
init.sysvinitはbusyboxではない。うーむ。
出所がわからないので、initもbusyboxのを見てみよう。
busyboxでは、initのことしか出てこない。
linuxrcは、initのオプションでinitrdを有効にすることでできる。
initrdって「initialize RAM disk」の略だろうか。
よくよくkernel_init()を見ると、linuxrcが実行されるのはRAM diskで実行させたときだけのような気がする。
となると、/sbin/initだけ気にすればよいか。
えーい、めんどうなので、busyboxを自分でビルドして差し替えてみよう。
VFS: Mounted root (nfs filesystem) on device 0:12. Freeing init memory: 168K Warning: unable to open an initial console. Kernel panic - not syncing: No init found. Try passing init= option to kernel. |
これは・・・4つのinitのうちどれかを実行しようとしたけど、どれもだめだったときのpanicではないか。
ファイルはあるし、アクセス権もroot.rootにあわせたんだけどなぁ。
「unable to open…」は、kernelが/dev/consoleをオープンできなかったときに出している。
PSPで使われていた/devを持ってくると出なくなった。
もしかするとファイルシステムが見えていないのでは、と思ったが、そういうわけではなさそうだ。
しかしinitの実行はできていない。
PSPのinit.sysvinitをコピーしてもだめだったので、initの問題ではなさそうだ。
では、PSP環境の/sbin/initを削ってみると・・・シェルが起動した。
ってことは、やはりPSP環境版はちゃんと動くんだ。
そういえば、PSP環境版で固まると思ったのも「Starting thttpd」で止まってしまうからというだけだ。
rc5.dからhttpdを取り除くといいのかと思ったが、そうではないようだ。
たぶん、httpdは動いているが、その次のomap-demoが動かずに固まっているか、動いているけどディスプレイに表示されていないかだろう。
整理できなくなってきたので、一旦筆を置こう。
nfsvers=3を指定することで、BeagleBoardからnfsブートすることができた。
よかったよかった。
Linux version 2.6.32 (xxx@kurokiri) (gcc version 4.4.3 (GCC) ) #21 Sat Oct 15 14:07:24 JST 2011CPU: ARMv7 Processor [411fc083] revision 3 (ARMv7), cr=10c53c7f CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache Machine: OMAP3 Beagle Board Memory policy: ECC disabled, Data cache writeback OMAP3430/3530 ES3.1 (l2cache iva sgx neon isp 720m ) SRAM: Mapped pa 0x40200000 to va 0xfe400000 size: 0x100000 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 25146 Kernel command line: mem=99M console=ttyS2,115200n8 noinitrd ip=192.168.0.22::192.168.0.1:255.255.255.0 root=/dev/nfs nfsroot=192.168.0.2:/home/xxx/Qt/nfs,nfsvers=3,nolock,rsize=1024,wsize=1024 rootfstype=nfs mpurate=600 omapfb.rotate=1 omapfb.vrfb=y vram=10M omapfb.vram=0:10M omapdss.def_disp=dvi omapfb.mode=dvi:720x480MR-16@60Booting kernel: `0:10M' invalid for parameter `omapfb.vram' PID hash table entries: 512 (order: -1, 2048 bytes) Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) Memory: 99MB = 99MB total Memory: 94904KB available (4312K code, 811K data, 168K init, 0K highmem) Hierarchical RCU implementation. NR_IRQS:402 Clocking rate (Crystal/Core/MPU): 26.0/332/500 MHz Reprogramming SDRC clock to 332000000 Hz GPMC revision 5.0 IRQ: Found an INTC at 0xfa200000 (revision 4.0) with 96 interrupts Total of 96 interrupts on 1 active controller OMAP GPIO hardware version 2.5 OMAP clockevent source: GPTIMER12 at 32768 Hz Console: colour dummy device 80x30 Calibrating delay loop... 514.67 BogoMIPS (lpj=2011136) Mount-cache hash table entries: 512 CPU: Testing write buffer coherency: ok regulator: core version 0.5 NET: Registered protocol family 16 Found NAND on CS0 Registering NAND on CS0 Unable to get DVI reset GPIO Target VDD1 OPP = 5, VDD2 OPP = 3 OMAP DMA hardware revision 4.0 bio: create slab <bio-0> at 0 SCSI subsystem initialized usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb i2c_omap i2c_omap.1: bus 1 rev3.12 at 2600 kHz twl4030: PIH (irq 7) chaining IRQs 368..375 twl4030: power (irq 373) chaining IRQs 376..383 twl4030: gpio (irq 368) chaining IRQs 384..401 regulator: VUSB1V5: 1500 mV normal standby regulator: VUSB1V8: 1800 mV normal standby regulator: VUSB3V1: 3100 mV normal standby twl4030_usb twl4030_usb: Initialized TWL4030 USB module regulator: VMMC1: 1850 <--> 3150 mV normal standby regulator: VDAC: 1800 mV normal standby regulator: VPLL2: 1800 mV normal standby regulator: VSIM: 1800 <--> 3000 mV normal standby regulator: VAUX3: 1800 mV normal standby regulator: VAUX4: 1800 mV normal standby i2c_omap i2c_omap.2: bus 2 rev3.12 at 100 kHz i2c_omap i2c_omap.3: bus 3 rev3.12 at 100 kHz Switching to clocksource 32k_counter musb_hdrc: version 6.0, musb-dma, otg (peripheral+host), debug=0 musb_hdrc: USB OTG mode controller at fa0ab000 using DMA, IRQ 92 NET: Registered protocol family 2 IP route cache hash table entries: 1024 (order: 0, 4096 bytes) TCP established hash table entries: 4096 (order: 3, 32768 bytes) TCP bind hash table entries: 4096 (order: 2, 16384 bytes) TCP: Hash tables configured (established 4096 bind 4096) TCP reno registered UDP hash table entries: 256 (order: 0, 4096 bytes) UDP-Lite hash table entries: 256 (order: 0, 4096 bytes) NET: Registered protocol family 1 RPC: Registered udp transport module. RPC: Registered tcp transport module. RPC: Registered tcp NFSv4.1 backchannel transport module. NetWinder Floating Point Emulator V0.97 (double precision) ashmem: initialized VFS: Disk quotas dquot_6.5.2 Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) msgmni has been set to 185 alg: No test for stdrng (krng) io scheduler noop registered io scheduler deadline registered io scheduler cfq registered (default) Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled serial8250.0: ttyS0 at MMIO 0x4806a000 (irq = 72) is a ST16654 serial8250.1: ttyS1 at MMIO 0x4806c000 (irq = 73) is a ST16654 serial8250.2: ttyS2 at MMIO 0x49020000 (irq = 74) is a ST16654 console [ttyS2] enabled brd: module loaded loop: module loaded pegasus: v0.6.14 (2006/09/27), Pegasus/Pegasus II USB Ethernet driver usbcore: registered new interface driver pegasus ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver ehci-omap ehci-omap.0: OMAP-EHCI Host Controller ehci-omap ehci-omap.0: new USB bus registered, assigned bus number 1 ehci-omap ehci-omap.0: irq 77, io mem 0x48064800 ehci-omap ehci-omap.0: USB 2.0 started, EHCI 1.00 hub 1-0:1.0: USB hub found hub 1-0:1.0: 3 ports detected Initializing USB Mass Storage driver... usbcore: registered new interface driver usb-storage USB Mass Storage support registered. usbcore: registered new interface driver usbserial usbserial: USB Serial Driver core USB Serial support registered for cp210x usbcore: registered new interface driver cp210x cp210x: v0.09:Silicon Labs CP210x RS232 serial adaptor driver USB Serial support registered for FTDI USB Serial Device usbcore: registered new interface driver ftdi_sio ftdi_sio: v1.5.0:USB FTDI Serial Converters Driver USB Serial support registered for pl2303 usbcore: registered new interface driver pl2303 pl2303: Prolific PL2303 USB to serial adaptor driver android init android_probe pdata: c048f2dc android_bind android_usb gadget: android_usb ready musb_hdrc musb_hdrc: MUSB HDRC host driver musb_hdrc musb_hdrc: new USB bus registered, assigned bus number 2 hub 2-0:1.0: USB hub found hub 2-0:1.0: 1 port detected f_adb init android_register_function adb adb_bind_config f_mass_storage init android_register_function usb_mass_storage f_accessory init android_register_function accessory mice: PS/2 mouse device common for all mice input: gpio-keys as /devices/platform/gpio-keys/input/input0 using rtc device, twl_rtc, for alarms twl_rtc twl_rtc: rtc core: registered twl_rtc as rtc0 twl_rtc twl_rtc: Power up reset detected. twl_rtc twl_rtc: Enabling TWL-RTC. i2c /dev entries driver Linux video capture interface: v2.00 sn9c102: V4L2 driver for SN9C1xx PC Camera Controllers v1:1.47pre49 usbcore: registered new interface driver sn9c102 usbcore: registered new interface driver uvcvideo USB Video Class driver (v0.1.0) mmci-omap-hs mmci-omap-hs.1: err -16 configuring card detect usbcore: registered new interface driver usbhid usbhid: USB HID core driver logger: created 64K log 'log_main' logger: created 256K log 'log_events' logger: created 64K log 'log_radio' logger: created 64K log 'log_system' Advanced Linux Sound Architecture Driver Version 1.0.21. usb 1-2: new high speed USB device using ehci-omap and address 2 No device for DAI omap-mcbsp-dai-0 No device for DAI omap-mcbsp-dai-1 No device for DAI omap-mcbsp-dai-2 No device for DAI omap-mcbsp-dai-3 No device for DAI omap-mcbsp-dai-4 OMAP3 Beagle SoC init asoc: twl4030 <-> omap-mcbsp-dai-0 mapping ok ALSA device list: #0: omap3beagle (twl4030) TCP cubic registered NET: Registered protocol family 17 NET: Registered protocol family 15 Power Management for TI OMAP3. Switched to new clocking rate (Crystal/Core/MPU): 26.0/332/600 MHz IVA2 clocking rate: 430 MHz SmartReflex driver initialized VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 1 regulator_init_complete: incomplete constraints, leaving VAUX3 on regulator_init_complete: incomplete constraints, leaving VDVI on regulator_init_complete: incomplete constraints, leaving VDAC on twl_rtc twl_rtc: setting system clock to 2000-01-01 00:00:00 UTC (946684800) hub 1-2:1.0: USB hub found hub 1-2:1.0: 4 ports detected usb 1-2.2: new full speed USB device using ehci-omap and address 3 pegasus 1-2.2:1.0: setup Pegasus II specific registers IP-Config: No network devices available. fail ic_open_devs() pegasus 1-2.2:1.0: eth0, MELCO/BUFFALO LUA2-TX, 00:40:26:c0:bf:af mmc0: new high speed SD card at address b368 mmcblk0: mmc0:b368 SDC 1.85 GiB mmcblk0: p1 pegasus 1-2.2:1.0: update_eth_regs_async, status -22 IP-Config: Complete: device=eth0, addr=192.168.0.22, mask=255.255.255.0, gw=192.168.0.1, host=192.168.0.22, domain=, nis-domain=(none), bootserver=255.255.255.255, rootserver=192.168.0.2, rootpath= Looking up port of RPC 100003/3 on 192.168.0.2 Looking up port of RPC 100005/3 on 192.168.0.2 NFS: sending MNT request for server:/home/xxx/Qt/nfs NFS: MNT request succeeded VFS: Mounted root (nfs filesystem) on device 0:12. Freeing init memory: 168K INIT: version 2.86 booting Please wait: booting... Starting udev modprobe: FATAL: Could not load /lib/modules/2.6.32/modules.dep: No such file or directory modprobe: FATAL: Could not load /lib/modules/2.6.32/modules.dep: No such file or directory modprobe: FATAL: Could not load /lib/modules/2.6.32/modules.dep: No such file or directory modprobe: FATAL: Could not load /lib/modules/2.6.32/modules.dep: No such file or directory Populating dev cache Remounting root file system... WARNING: Couldn't open directory /lib/modules/2.6.32: No such file or directory FATAL: Could not open /lib/modules/2.6.32/modules.dep.temp for writing: No such file or directorymodprobe: FATAL: Could not load /lib/modules/2.6.32/modules.dep: No such file or directory modprobe: FATAL: Could not load /lib/modules/2.6.32/modules.dep: No such file or directory root: mount: mounting rootfs on / failed: No such file or directory root: mount: mounting usbfs on /proc/bus/usb failed: No such file or directory Setting up IP spoofing protection: rp_filter. Configuring network interfaces... done. Wed Dec 2 19:18:00 UTC 2009 Configuring update-modules WARNING: Couldn't open directory /lib/modules/2.6.32: No such file or directory FATAL: Could not open /lib/modules/2.6.32/modules.dep.temp for writing: No such file or directoryINIT: Entering runlevel: 5 Starting telnet daemon. modprobe: FATAL: Could not load /lib/modules/2.6.32/modules.dep: No such file or directory Starting syslogd/klogd: done Starting thttpd. |
あれ、止まってる・・・。
/lib/modules/2.6.32がない、というのが大きいようだ。
この環境は、元はといえばTI提供のもので、kernelは2.6.29-rc3-omap1だったのだ。
しかし、あまりにも動かなかったので、Androidで使っていた2.6.32を使っている。
その差が現れたか・・・。
対策は２つしかなく、
のどっちかだ。
あまり考えず、TIのAndroid kernelでmake modulesさせてみよう。
make modules_install・・・だけだと/lib以下にコピーされるので、INSTALL_MOD_PATHを指定してから実行。
INIT: version 2.86 booting Please wait: booting... Starting udev udev: starting version 141 udevd[541]: inotify_add_watch(3, (null), 10) failed: Bad address udevd[541]: inotify_add_watch(3, (null), 10) failed: Bad address udevd[541]: inotify_add_watch(3, (null), 10) failed: Bad address udevd[541]: inotify_add_watch(3, (null), 10) failed: Bad address udevd[541]: inotify_add_watch(3, (null), 10) failed: Bad address udevd[541]: inotify_add_watch(3, (null), 10) failed: Bad address udevd[541]: inotify_add_watch(3, (null), 10) failed: Bad address udevd[541]: inotify_add_watch(3, (null), 10) failed: Bad address udevd[541]: inotify_add_watch(3, (null), 10) failed: Bad address udevd[541]: inotify_add_watch(3, (null), 10) failed: Bad address udevd[541]: inotify_add_watch(3, (null), 10) failed: Bad address udevd[541]: inotify_add_watch(3, (null), 10) failed: Bad address udevd[541]: inotify_add_watch(3, (null), 10) failed: Bad address udevd[541]: inotify_add_watch(3, (null), 10) failed: Bad address udevd[541]: inotify_add_watch(3, (null), 10) failed: Bad address udevd[541]: inotify_add_watch(3, (null), 10) failed: Bad address udevd[541]: inotify_add_watch(3, (null), 10) failed: Bad address udevd[541]: inotify_add_watch(3, (null), 10) failed: Bad address udevd[541]: inotify_add_watch(3, (null), 10) failed: Bad address udevd[541]: inotify_add_watch(3, (null), 10) failed: Bad address udevd[541]: inotify_add_watch(3, (null), 10) failed: Bad address udevd[541]: inotify_add_watch(3, (null), 10) failed: Bad address udevd[541]: inotify_add_watch(3, (null), 10) failed: Bad address udevd[541]: inotify_add_watch(3, (null), 10) failed: Bad address udevd[541]: inotify_add_watch(3, (null), 10) failed: Bad address udevd[541]: inotify_add_watch(3, (null), 10) failed: Bad address Remounting root file system... root: mount: mounting rootfs on / failed: No such file or directory root: mount: mounting usbfs on /proc/bus/usb failed: No such file or directory Setting up IP spoofing protection: rp_filter. Configuring network interfaces... done. Wed Dec 2 19:18:00 UTC 2009 INIT: Entering runlevel: 5 Starting telnet daemon. Starting syslogd/klogd: done Starting thttpd. |
やっぱり、無理矢理はだめなんかね・・・。
前々回、USB NICを認識する前にNFSサーバにマウントしようとしたので、失敗した。
前回、USB NIC認識に失敗したらリトライするようにして、次のエラーが出るところまで進んだ。
Looking up port of RPC 100003/2 on 192.168.0.2 Looking up port of RPC 100005/1 on 192.168.0.2 Root-NFS: Server returned error -22 while mounting /home/xxx/Qt/nfs
-22という値が、うちで使っているUSB NICドライバの出すエラー番号と一致するので調べていたけど、何となく関係がなさそうな気がした。
そこでもう一度検索してみると、こんなのがあった。
http://www.denx.de/wiki/DULG/LinuxRootFilesystemUsingNFSVersion3
おお。
うちのNFSサーバも、unfs3を使っているからバージョン3だ。
ってことは、bootargsのnfsrootに"nfsvers=3"を追加する必要があるってことか。
これだといいなぁ。
起きたら確認しよう。
普段、２時に寝て７時くらいに起きるから、たまに休日に早く寝るとこんな変な時間に起きてしまうのだ。
ああもったいない・・・。
なぜだろうねぇ。
LUA2-TXというのは、USBのNICだ。
Buffaloで販売しているが、ずいぶん前のものだから、もう廃番になっているかも。
これをBeagleBoardのNICとして使っているのだが、しばしばupdate_eth_regs_async()で-22だといわれる。
BeagleBoardだけじゃなく、PCのLinuxで使っていてもそうなったかもしれん(今はWindowsを動かしているので試せない)。
警告なのかエラーなのかわからないのは気持ちが悪いので、わかる範囲で調べてみよう。
-22は、中で呼ばれているusb_submit_urb()の戻り値だ。
しかしメッセージの表示条件は、netif_msg_drv(pegasus)が真の時というだけで、戻り値がエラーの場合というわけではない。
戻り値が-ENODEV(指定された USB デバイスかバスは存在しません)ならば、そのときはdetachしにいってる。
-22はそうなると、errnoのメンバーでいいってことになり、それなら-EINVALということだ。
こちらを参考にすると、
a) 無効 (または、使えない) な転送の種類が指定されました
b) 無効か使えない転送周期です
c) ISO: 転送間隔の変更が試みられました
d) ISO: number_of_packets (パケットの数) が 0 未満です
e) その他の場合
の、どれかというわけだ。
どれだろう・・・。
そしてもう１つ。
update_eth_regs_async()はusb_submit_urb()の戻り値を返すけれども、呼び出し元はそれを捨てているのだ。
うーん、エラーは通常戻ってくるはずがないから捨てているのか、どっちでもいいから捨てているのか、単なる実装ミスか・・・。
今気付いたが、update_eth_regs_async()の呼び出し元はctrl_callback()だ。
そしてctrl_callback()はコールバック関数のようで、設定はusb_fill_control_urb()内の引数みたいだ。
このusb_fill_control_urb()を呼び出すのは・・・update_eth_regs_async()など。
ctrl_callback()の関数コメントに「Aargh!!! I _really_ hate such tweaks」と書いてあるのはそういうわけか。
usb_fill_control_urb()が正常に終わり、なおかつレジスタ設定がまだ残っている場合は再びupdate_eth_regs_async()を呼び出し直して設定を行い、エラーになったら抜けることになっているのではないだろうか。
あまり通るルートじゃないけれど、他にいい方法が思いつかなかったとかかなぁ。
それなら「hate」っていう気持ちもわかる。
でもなぁ・・・それならprintk()使ってエラー出力しないよなぁ。
ぐるぐるループさせる方法を「hate」っていってるだけであって、エラーになっているのはやっぱりエラーと考えるのが普通のように思えてきた。
わからんので、Linux環境に戻して確認するか。
http://www.usupi.org/info/koneta.html#nfsroot
えー、それしかないの？？？
cgrepで検索すると、「No network devices available」はnet/ipv4/ipconfig.c:255にあった。
ic_open_devs()という関数でネットワークデバイスを探している。
これよりも前にデバイスが存在しないと、エラーになるということだ。
では、待たせてみよう。
for_each_netdev()でループしている箇所が２つあるので、２つめの方をリトライさせるようにした。
int retry=3;while(retry--) {for_each_netdev(&init_net, dev) {・・・}set_current_state(TASK_INTERRUPTIBLE);schedule_timeout(msecs_to_jiffies(1000));printk("retry : %d\n", retry);}
まあ、こんなイメージだ。
そうすると・・・
pegasus 1-2.2:1.0: setup Pegasus II specific registersretry : 2retry : 1retry : 0IP-Config: No network devices available.pegasus 1-2.2:1.0: eth0, MELCO/BUFFALO LUA2-TX, 00:40:26:c0:bf:af
だめやん。
しかたなくさかのぼると、ip_auto_config()から呼び出されていた。
ここに「try_try_again」という、なんとなくリトライしてくれそうなラベルがあった。
ic_open_devs()が失敗するとreturnしていたので、それをgoto try_try_againに変更。
pegasus 1-2.2:1.0: setup Pegasus II specific registers
IP-Config: No network devices available.
fail ic_open_devs()
pegasus 1-2.2:1.0: eth0, MELCO/BUFFALO LUA2-TX, 00:40:26:c0:bf:af
pegasus 1-2.2:1.0: update_eth_regs_async, status -22
IP-Config: Complete:
device=eth0, addr=192.168.0.22, mask=255.255.255.0, gw=192.168.0.1,
host=192.168.0.22, domain=, nis-domain=(none),
bootserver=255.255.255.255, rootserver=192.168.0.2, rootpath=
Looking up port of RPC 100003/2 on 192.168.0.2
Looking up port of RPC 100005/1 on 192.168.0.2
Root-NFS: Server returned error -22 while mounting /home/xxx/Qt/nfs
VFS: Unable to mount root fs via NFS, trying floppy.
List of all partitions:
b300 1947648 mmcblk0 driver: mmcblk
b301 263283 mmcblk0p1
No filesystem could mount root, tried: nfs
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(2,0) |
おお、リトライによって認識され、進んでいるように見える。
PCからpingしても通ったので、少しは動いたのだろう。
赤文字で書いてあるように、サーバがエラーを返したのだろう。
NFSサーバ側がうまく対応できていない、と信じたい。
このログは、fs/nfs/nfsroot.c:510で出している。
エラー元はmount_clnt.c。
では、とdprintkをprintkに定義し直してビルド。
NFS: sending MNT request for server:/home/xxx/Qt/nfs
NFS: MNT server returned result -22
よくわからん。
-22って値が、pegasusのエラー値と同じなのが気になる。
update_eth_regs_async()のエラー原因が未だにわかってないからなぁ。
関数名からすると、チップに対してUSBで非同期にレジスタ変更を行おうとしているのが失敗した、ってことなのかな。
うーむ。
うまくいかんシリーズです。
前回から続けている、BeagleBoardをNFSブートさせたいというお話。
bootargsがよくないのでうまくいっていないのかと思ったが、ログを見るとUSB-LANを認識し終わっていないときにやろうとしているのか？という気がした。
| Linux version 2.6.32 (xxxx@xxxx) (gcc version 4.4.3 (GCC) ) #14 Mon Oct 10 21:13:36 JST 2011 |
pegasusというのは、うちで使っているUSB-LANの「LUA2-TX」だ。
昔、実家でADSLを引けそうだったので買ったけど、距離が遠すぎて回線につなげられず、放置されていたのだ。
赤文字にしたところが、ちょうどデバイス認識の前後に挟まっているのか、NFSを使いたいからデバイスを認識し始めたのか知らないが、いずれにせよ間に合っていないように見える。
nfsとは関係ないが、bootargsに関するエラーも気になる。
Booting kernel: `0:10M' invalid for parameter `omapfb.vram'
Documentation/arm/OMAP/DSSには、こう書いてある。
omapfb.vram=<fbnum>:<size>[@<physaddr>][,...]
fb0に対してやってるんだけどなあ。
まあ、後で調べよう。
液晶モニタを代えたのはいいが、色がまだ慣れないなぁ。
そんなわけで、今回は昨日の調査結果だけまとめる。
まず、まだNFS起動はできていないことを報告せねばなるまい。
いろいろと考えた末、Androidで使っていたカーネルを使うことにした。
そしてbootargsは、なるべくPSPの設定に従いつつも、Androidのに合わせていった。
昨日のカーネル起動から先が出ていないのは、ttyS2を指定してなかったからだったのだけど、そういったパラメータを合わせていったのだ。
そうすると、ずいぶんとするする進むようになったが、NFSがだめ。
ログは残していないのだが、IPアドレスの設定に失敗しているようなのだ。
なんとなく、USB LANの認識が後になっているように見えた。
ネットで検索すると、これが最初の方に出てくる。
Mount BeagleBoard Root Filesystem over NFS via USB
なんか全体的に違和感があったのだが、ようやくわかった。
これは、BeagleBoardをUSB LANとして使うための設定っぽい。
IPアドレスを指定してもだめだが、その場合はかなり粘ってからあきらめている。
DHCPにすると、するっとあきらめている。
うーむ。
動かしている人のbootargsをみると、こんなのだった。
ip=192.168.1.1::255.255.255.0 nolock,rsize=1024,wsize=1024
ここら辺の違いかなぁ。
週末に試してみよう。
前準備は整ったということにして、進めていこう。
http://processors.wiki.ti.com/index.php/Building_Qt
今回、OpenGL|ESはやらない。
なんかめんどくさそうだからだ。
まあ、後で必要になったら、やろう。
Qt embeddedライブラリはダウンロードして、ターゲットボードの準備はできてるよね。
・・・ターゲットボードはできていないので、やりますやります。
SDカードをvfat形式でフォーマット。
MLOは、BeagleBoardのサイトから入手。
u-boot.binとuImageは、PSPのimagesから持ってきた。
rootfsも持ってこよう・・・としたところで、迷いが生じた。
とりあえずramdiskにしておこうかと思ったけど、nfsの方がいいんじゃなかろうか。
ビルドして、コピーして、というのは、けっこうめんどくさいのだ。
まず、/homeの自分のところに、PSPのimages/fs/omap3530のnfs.tar.gzを解凍。
sudoじゃないと失敗したような気がする。
ここではこの場所を/home/qtnfsと呼ぼう。
ついで、/etc/exportsを書く。
なかったので、新規作成し、eLinuxを見ながら書いた。
BeagleBoardは、192.168.0.22に割り当てるつもり。
http://elinux.org/BeagleBoardFAQ#NFS
/home/qtnfs 192.168.0.22(rw,no_root_squash,no_all_squash,async)
さて、うちはUbuntu11.04なんだけど、nfsはどうやればいいんだろうか？
$ sudo apt-get install unfs3
$ sudo apt-get install nfs-common
こんなので、インストールできたようだ。
$ showmount -e 192.168.0.2
Export list for 192.168.0.2:
/home/qtnfs 192.168.0.22
いいのかな？
では、とりあえず起動してみよう。
だめやった。
まず、u-boot.binが読み込めてないというか、u-boot.binを読み込んでから先が進まない。
これはおそらく、xloaderを書き換えてないせいじゃないかなぁ。
とりあえず、MLOをもらったのと同じところからu-boot.binをもらうと進んだ。
進んだが・・・カーネルの起動あたりで止まった。
Texas Instruments X-Loader 1.4.4ss (Mar 8 2011 - 08:51:11)Beagle Rev C4Reading boot sectorLoading u-boot.bin from mmcU-Boot 2010.03 (Feb 20 2011 - 20:15:58)OMAP3530-GP ES3.1, CPU-OPP2, L3-165MHz, Max clock-720MhzOMAP3 Beagle board + LPDDR/NANDI2C: readyDRAM: 256 MBNAND: 256 MiBIn: serialOut: serialErr: serialProbing for expansion boards, if none are connected you'll see a harmless I2C error.timed out in wait_for_pin: I2C_STAT=0I2C read: I/O errorUnrecognized expansion board: 0Beagle Rev C4Die ID #1232000400000000040365fa1702200aHit any key to stop autoboot: 0mmc1 is availablereading boot.scr568 bytes readRunning bootscript from mmc ...## Executing script at 82000000mmc1 is availablereading uImage2381156 bytes readsetenv - set environment variablesUsage:setenv name value ...- set environment variable 'name' to 'value ...'setenv name- delete environment variable 'name'## Booting kernel from Legacy Image at 80200000 ...Image Name: Linux-2.6.32Image Type: ARM Linux Kernel Image (uncompressed)Data Size: 2381092 Bytes = 2.3 MBLoad Address: 80008000Entry Point: 80008000Verifying Checksum ... OKLoading Kernel Image ... OKOKStarting kernel ...
単にsetenvあたりがおかしいだけみたいだと思ってたのだが、どうもそう簡単な話ではなさそうだ。
bootargsがどうのこうのいう前に、カーネルが始まってない。
カーネルが起動して、ユーザランドに切り替わるあたりまではだいたい進むものだ。
つまり、カーネルがBeagleBoardとあってないということか。
うーん、PSPはBeagleBoard用ってわけじゃないから、ビルドしなおさないとだめなのかな。
さて、ここからは手探りだ。
今まではAndroid向けに動かしていたので、シェルらしいシェルもない。
busyboxがあればいいのだけど、それではこのスペックにはもったいない気がする。
Qtを動かすのが目的なので、なにかウィンドウシステムがほしいところだ。
そんなわけで、Qtのビルドページを見てみよう。
http://processors.wiki.ti.com/index.php/Building_Qt
Qt Embeddedのソース、それとTIの提供するソフトウェアパッケージのリンクがある。
まあQtはいいとして、わからないのは残りだ。
DVSDK、PSP、GFX SDK。
順に見ていくか。
DVのSDK。
DVは「Digital Video」のようだ。
とりあえずSetup.binをダウンロードして、chmodで+xして実行させた。
すると、インストーラが起動して、自分のhome下にインストールされた。
http://software-dl.ti.com/dsps/dsps_public_sw/psp/omap3_00/03_00_00_04/index_FDS.html
Platform Support Package。
ここでダウンロードするのは、PSPのSDKみたいだ。
http://software-dl.ti.com/dsps/dsps_public_sw/gfxsdk/3_01_00_06/index_FDS.html
OMAP3530には、POWER VR SGX Graphicsとか、DSPとかが載っているので、それを使うためのSDKなのだろう。
ダウンロードだけしてみようとしたが、my.TIの会員登録が必要そうだった。
うーむ、と思ったけど、とりあえず登録してダウンロードした。
と、ここまでやっていて思ったが、この「Building Qt」は、文字通りQtをビルドするための環境について書いてあるのか？
しかし、ARM用のQtライブラリなんてないだろうから、やっぱり自分で環境を作るしかないか。
気にせず続きを読んでいこう。
ここまでは単に、リンクはここにありますよ、だけで、これらをどうするのかは書かれていなかった。
ちょっと早まってしまったようなので、落ち着こう。
Qtをビルドする前に、ターゲット環境の設定をしよう。
PSPにファイルシステムは入ってるんだけど、ramdiskかnfsのなのだな。jffs2もある。
しかし私はSD上にパーティションを作って、そこに置いておきたいのだ。ext3とか4とかで。
まあ、何とでもなるので、ここは手順通りにやってみよう。
コンパイラは、やはりCode Sourcery。
注意書きとして「kernelやfilesystemをビルドしたのと同じバージョンを使え」とある。
PSPのManifest htmlファイルを見ると、2007q3を使っているらしい。
うちにインストールされているのは、2010.09-50みたい。
https://sourcery.mentor.com/sgpp/lite/arm/portal/subscription3057
あれ、でもPSPのPDFファイルでは、2009q1となっているな・・・。
どちらを信用したらいいんだ？
PDFには、PSPのバージョンが書いてある。
Manifestには、バージョンが書いていない。
よって、PDFを信じることにしよう。
2009q1も2種類あったけど、これはupdateの方にした。
Ubuntuでbinファイルを実行したら、dashはだめだ・・・っていわれた。
今までbashだと思い込んでいたが、実はdashだったらしい。
よくわからぬまま、コンソールに出てきたまま実行して、No、と答えるとbashになった。
bootargsは、動かすときに読めばいいや。
ここから先は、実際にQtのビルドになる。
ひとまず休憩だ。
今までもBeagleBoardを使ってきたが、それはAndroidを動かすためのものであった。
BeagleBoardでQtを始める前に、一度おさらいしておこう。
まず、このサイト。
http://beagleboard.org/
基本的な情報は、ここから手に入れることができるし、たどることができる。
「Getting Started」からはPDFマニュアルが入手できるので、読んでおこう。
とりあえずBeagleBoardを動かす「だけ」であれば、シリアルポートとの接続ができるPC(ケーブルも)と、BeagleBoardからシリアルポートを引っ張り出すコネクタ、USBのminiB-Aケーブルがあればいい。
でも、これだけだとすぐにがっかりしてしまうだろうから、SDカードとHDMI-DVI変換ケーブルはほしいところ。
ACアダプタはUSBから電源供給できるので不要なのかもしれないが、私は使っている。
USBマウスとUSBキーボードも用意し、セルフパワーのUSBハブもあるとよいな。
ああそうそう、ネットワークも使うなら、USBのLANボードもあったらよいだろう。
まあ、用途次第だ。
BeagleBoard(ノーマル)にはFLASHがあり、そこにLinuxカーネルなんかを置くことができる。
でも、私は何するかわからないから、FLASHは最低限にして、いるものはSDカードに置いている。
とりあえず、MLO、u-boot.bin、uImageがあればよい。
よく書かれているのでここにも書いておくが、SDをフォーマットしたら一番最初にMLOをvfatパーティションに置かなくてはならない。
理由は知らないのだが・・・。
推測だが、BeagleBoardの標準ブートローダXLoaderが「もしSDカードが挿してあればvfatパーティションの最初のディレクトリエントリを見て、そこにMLOというファイルがあれば読み込む」なんて仕組みになってるんじゃないだろうか。
動作確認するのであれば、ここからファイルを持って行くのがよかろう。
http://code.google.com/p/beagleboard/wiki/BeagleboardRevC3Validation
私は、MLOとu-boot.binをここからもらったと思う。
http://www.angstrom-distribution.org/demo/beagleboard/
ここまでで、BeagleBoardの動作確認はできたと思う。
Linuxのカーネルも動いたことだろう。
さて、次は何をしましょうかね。
BeagleBoard用に、今まではDisplayLinkのモニタを使っていた。
まあ、これはこれで悪くないのだけど、画面が遅いのだな。
これは、DisplayLinkのドライバを見てみればわかるけど、16bitデータの更新したブロックだけをRLEかそのままかで転送しているからだ。
製品版のドライバでは、もうちょっとすぐれた圧縮方式が使われている、というような記述を見たような気がする。
BeagleBoardの画面出力コネクタはHDMIだけど、出力規格はDVI-Dになっている。
それを使用できると、BeagleBoardのCPUが持つDSP機能が使えて、表示が速くできる。
以前Androidで試したときは「こりゃ別物だ」と思うくらいに速かった。
そのためにはDVI-Dのモニタがいるんだけど、私の作業机は狭いので、小さいモニタがほしかった。
探していたんだけど、今回の事態を受け、HDMI可のモニタをメインにし、使っていたモニタをBeagleBoard用にした。
なんか、ぜいたくだ。
試したのは、こちら。
http://processors.wiki.ti.com/index.php/Qt_on_BeagleBoard
そう、Qtだ。
やっぱり、C++で作りたいのよね。
Androidもいいんだけど、Qtでも作れるとなおよし、というところ。
まあ、どっちも使いこなしていないんだけどね。
まず、Method#1 にあるZipをダウンロード。
解凍すると、READMEが入っているので、それに従ってbinファイルを実行。
そしたらまたREADMEファイルが入ったフォルダができるので、それに従ってSDカードを作成。
READMEでは、環境変数を設定してFLASHに書き込むようになっているけど、Androidなどもやるのでboot.scrを作成してSDカードのvfatパーティションに置いた。
これが初回動かなくてねぇ。
理由はよくわからずじまい。
もう１回、bzcatしてSDに書き込むところをやり直したらうまくいった。
まあ、気にすまい。
SDを入れて起動すると、Linuxっぽいログイン画面が出てくる。
USBキーボードを最初から挿して起動させると、ちゃんと入力できる。
rootで入る。
デモアプリが入っているので、それを動かす。
パスをREADMEにある場所に移動させ、適当なディレクトリに移動。
たとえばaffinを動かすなら、
$ ./affin -qws -display linuxfb
などとする。
Xなどが動いていれば、アプリ名だけでいいのかも。
よくわからんのが、マウス。
USBマウスを挿してからアプリを起動させると、何かは反応している。
しかしマウスカーソルが表示されないので、よくわからない。
もう１つわからんのが、画面サイズ。
結構なモニタの大きさなんだけど、アプリのウィンドウがそれよりも大きいのだ。
うーん、なんだ？
さて、他に何か書くことがあるだろうか？
私なりの開発の仕方を書き残しておこうか。
最初に買ったのは、PaSoRiではなくRC-S620/Sだ。
なぜ購入したのか忘れたけど、おそらくFeliCa Developers' Blog(今の名前)に記事があったためだろう。
http://blog.felicalauncher.com/sdk_for_air/?p=2677
RC-S620/SにUSBシリアル変換を接続して、パソコンと接続。
パソコン側は、Windows XPだ。
が、これは別に何でもいい。
使うのは、コンソールソフトだけだからだ。
私は、TeraTermを使った(TeraTermがあるからWindowsを使ったのかもしれない)。
RC-S620/Sのフレーム仕様は、PDFとして購入者は入手することができる。
が・・・肝心なコマンドの使い方が載っていない。
上記BlogではArduino向けではあるものの、初期化からPUSHまでのソースファイルがある。
これをまねすれば、だいたいのことはできる。
というのは、格好がよすぎるな。
他のコマンドが使ってみたいので、バイナリ値で検索をしてみたのだ。
そうしていくつか見てみると、どうもR/Wのコマンドはチップメーカーが違ってもそれほど体系に違いがなさそうであった。
そんなわけで、一番資料として充実していたPN533(NXP)のPDFをネットで入手し(これは公開されている)、RC-S620/Sのコマンド一覧(一覧だけはある)と比較して、同じコマンド名のものはだいたい動くみたいだった。
一番使い勝手のよいCommunicateThruEXも制覇し、カードコマンドが使えるようになったというわけだ。
CommunicateThruEXは、今は正式に仕様書があるので、いい時代になったと思う。
毎回書いているが、R/Wへのコマンドと、かざされているカードへのコマンドは別物だ。
R/Wへのコマンドは、R/Wのチップ依存だ。
しかしカードは、ISO18092みたいな形で規格がある。
まあ、FeliCaはISO18092よりも、JIS X6319なんかの方がいいのかもしれん。
CommunicateThruEXはR/Wへのコマンドで、何をするかというとデータ部をそのままカードコマンドとして送信してくれるのだ。
そのレスポンスは、CommunicateThruEXの戻り値という形で取得できる。
InDataExchangeやInCommunicateThruも似たコマンドだが、ちょろっと違う。
CommunicateThruEXこそFeliCaの特徴なのだ！と言い張ってもいいんじゃなかろうか。
このコマンドは、PN533みたいな海外チップにはないのよね。
組み込み用のR/Wが出てた。
http://www.sony.co.jp/Products/felica/business/products/RC-S494.html
んー、機能としてはRC-S620/Sの方が高そうだが、PN533などよりも安く仕立てられるのかもしれない。
安いPUSH端末を作るときなんかは、SONY製はちょっと高いなーという印象があった気がするのでね。
424kbps対応ではないのでFALPはできなさそうだけど、R/Wって視点からすると十分だろう。
(できんことはないか。)
あれ、シリアルって、UARTじゃなくてシリアルなんだ。
組み込み用ってよりは、PC向けなのかなぁ。
うろおぼえで書く、FeliCa Liteのこと。
第２弾だ。
まさか続くとは誰も思っていなかっただろう。
FeliCa Liteのいい点は、扱いやすいところだと思う。
私からすると、MIFARE Classicよりも扱いやすい。
読み書きは、「Read Without Encryption」と「Write Without Encryption」でできる。
withoutなので、暗号化無しということだ。
FeliCaだと縮退鍵とか認証とかいろいろ挟まって、たぶん難しいんじゃないかなー、と思う(やったことはない)。
FeliCaと違うのは(たぶん)、Read w/o Encは4ブロック連続、Write w/o Encは1ブロックしかアクセスできない。
まあ、困らんけどね。
システムコードが固定だとか、エリアがないとか、あるにはあるのだが、そういうものだと思えばよい。
システムコードの扱い方は、ちょっと違いがあるように思う。
もともと、FeliCa Lite用のシステムコードがあった。
これはワイルドカードでPollingすると取得できるシステムコードだ。
しかしいつしか、NDEF対応というかNFC-F対応というか、0x12FCにも対応したのだ。
0x12FCに対応するのは、MCレジスタを書き換える必要があったと思う(うろおぼえ)。
MCレジスタを書き換えるときは、だいたい１次発行するときで、１次発行するとNDEF対応ビットが固定化されてしまう。
SONYさんから出ている、FeliCa LiteをNDEF対応するツールがあるが、あれは確か０次発行状態のカードを１次発行するものだったと思う。
最近、忙しくて調べながら書く余裕がない。
なので、記憶に頼って書くことにする。
記憶に頼って書けそうなことと言えば、最近はFeliCa Liteのことくらいだ。
FeliCa Liteは、FeliCaの簡易仕様版みたいなところがある。
データについては暗号などのセキュリティ機能をカード側では持っていない。
3DESで計算した結果は取得できるので、それを使った「改ざんチェック」が行えるだけである。
その改ざんチェックも、カードデータが読み取る側が行う必要がある。
これが「片側認証」と言われるセキュリティである。
よって、用途として一番よいのは、データブロックには重要なデータを書かず、会員証のようなカード自身の正当性を確認する使い方ではないかと思う。
スイッチサイエンス社で、１枚350円くらいだ。
ただ、カード単体の値段で見ると、たぶんMifareの方が安いんじゃないかと思う。
UltraLightは64byteくらいのデータしか持てないけど、大量に仕入れたらかなり安くなりそうだ。
次世代のFeliCa Liteが出たら、もっと安くなってよいかも。
FeliCa Liteのデータは、200byteくらいだ。
ブロック数が13か14か忘れてしまった(でも調べない)。
１ブロックだけ、回数券風にカウントダウンするデータブロックがある。
今の値より小さな値しか書き込めなさそうなので、未だに試したことはない。
