2011/10/30

[libnfc]libnfcというのもある

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。

 

うーん。
うーーーーん・・・・・

[opennfc]ISO18092にどこまで対応しているのか?

Linux Editionをダウンロードし、解凍した。
中に「documents」というディレクトリがあり、そこにPorting Guideがあった。
また、「porting」にもいくつかある。
これらを見ていくしかない。
が、まずは概要が知りたいところだ。

http://open-nfc.org/wp/editions/porting/#hardware
ここを見ると、Open NFCはInside Secure社が主に開発しているので、自社のHW(MicroRead / SecuRead)で動くようにできている、とある。
まあ、それは仕方あるまい。
気になるのは、海外では14443が主に使われている、ということだ。
18092の対応があまりないのではないだろうか?

・SIS_NFC_0806-058 Open NFC - NFC HAL Protocol Specification v3.6
5 Card Protocols
なんか、ISO 14443のAとBしかやらなさそう。

・DIV_NFC_0804-250 NFC Standards v1.7
P2PはLLCPで、ISO18092に分類されているから、AndroidみたいにIsoDepしかない、ということはないだろう。

私はLLCPだけ動かせればいいんだけど、Open NFCを使うとなるとある程度の機能が動かないといけないんだよなぁ。
うーん、うーん・・・・。

じっくり見ていこうかと思ったが、LLCPのためだけにここまでがんばれるかどうか自信がない私であった。

[opennfc]Edition

Open NFCは、今の最新版が4.3.1 r0(11634)で、これは2011/10/10リリースだ。
エディションが5つある。

  • Core Edition
  • SDK Edition (previously called PC Edition)
  • Linux Edition
  • NFC HAL for MicroRead Edition
  • Android Edition / Android Add-on Edition

詳細は、各エディションのリリースノートを見てくれ、とのこと。
うーむ。

この中で、とりあえずわからない単語が出てきた。
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だ。

  • SDK Editionは、Win32でビルドしたもの、つまりWindows環境用らしい。
  • Core EditionはSDK Editionのスーパーセットになっていて、ソースコードも含んでいる。
  • Linux EditionはCore Editionと似ているが、移植層がLinuxになっている。
    ただし、Connection Center、NFC Simulator、AC File GeneratorなどはWin32版しかないので、それらを動かしたいならばWin32環境でやるしかないとのこと。

 


NFC Simulatorってのが気になるが、これはオープンソースではない。
Win32専用ってのは、そういうことなのだ。
仮想的なNFCデバイスを作り、NFCソフトウェアスタックをエミュレーションできるようなのだ。

どうやってやるのかと思ったが、そこにConnection Centerが出てくる。
これもWin32専用。
TCP/IPでデバイス間を接続するイメージらしい。
Linux Editionではこのあたりのツールが動作しないけど、対抗機としてWin32のマシンを用意できればよいようだ。

おっと、ここで注意が。

NFC Simulatorは、タグとしてType1, 2, 4をサポートしている。
つまり・・・FeliCaは対象外なのだ。
まあ、しょうがないかな。

 

そんなわけで、以降はLinux Editionを見ていく予定だ。

[nfc]LLCPを実装するのが面倒なら、探せばいいじゃないの

なんだこのタイトルは?
まあいいや・・・。

LLCP-1.1ドキュメントをちょっとだけ読んでいたのだが、自分で実装するのはめんどくさそうだ。
めんどくさいというか、ちゃんと動くものを作るまでにえらく時間がかかるだろう。
あんまりこの辺には興味がないので、さっさと終わらせてしまいたいのだが・・・。

 

ならば、実装されているものを探せばいいじゃないか、ということにようやく思い至った。
ネットで検索・・・。

出てきたのは、Open NFC
そういえば、以前も少しだけ見て、やめたことがあったな。
再び見るときがやってきたようだ。


Welcomeメッセージに、こんなことが書いてある。

Open NFC TMはNFCコントローラチップセットの上に載るNFC機能を実装したソフトウェアスタックである。

主な機能:

  • 幅広いNFCタグとプロトコルをサポート
  • Readerモード、カードエミュレーションモード、P2Pモードをサポート
  • BluetoothペアリングやWiFiペアリングなどのコネクションハンドオーバーをサポート
  • セキュアエレメントのカードエミュレーションをサポート
  • NFCハードウェア非依存スタック(NFC HAL)あり。NFCシミュレータソフトもある。
  • 移植性あり。
  • 無料です! Apache2.0ライセンス

 

つまりまあ、NFC Forumでドキュメントになっているようなことはすべて実装されているってことのようだ。
では、これからしばらくは、Open NFCのことを調べてみようかね。

2011/10/28

LLC Procedures

仕方ないので、LLC手順にどういうものがあるのかだけ見ていこう。
詳細を見る気力はない。


  • 5.2 Link Activation
  • 5.3 Normal Operation
  • 5.4 Link Deactivation

この3つが基本っぽい。
"Normal Operation"では、5.5~5.9のことができるようだ。
InitiatorかTargetかでちょっと違いそうなことが書いてある(読んでないけど)。

 

  • 5.5 Connectionless Transport Mode
  • 5.6 Connection-oriented Transport Mode

この2つは、UDPとTCPみたいな位置づけに見える。

 

  • 5.7 Aggregation
  • 5.8 Symmetry
  • 5.9 Service Discovery

この3つは、なんとなく別物って雰囲気が漂っている。
Service Discoveryは新顔で、たぶんNPPと関わりが深そうだ。
いつか読まねば。


ネタを小出しにしているように見えるだろうが、書きながら調べているだけだ。
そして、調べる時間があったら早く寝たいというところ。
まあ、しばしこんなペースでしかできませんな。

2011/10/27

データをやりとりする単位がわかったら、次はシーケンスを確認するべし

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」だ、と思ったが・・・図がない。
手順なら、シーケンス図がほしいじゃないか・・・。

2011/10/26

[nfc]LLC PDU Format

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

 

例を見らんとわからんなぁ。

2011/10/25

[nfc]DEPのイメージ

llcp

 

私のNFC-DEPに持つイメージは、こんな感じだ。

イメージを図にするとしても、解釈したい内容によって図の作りが変わってくる。
今回は、アプリからNFC-DEPで送信するときはこういう風に扱われるんですよ、という図にしようとして、挫折した感じだ。

 

DEPは、R/W同士で行うものだろう。
だからPCDが向かい合っている。

PCD間は、もちろんNFC-DEPでデータ交換している。

ではその上に何が来るかというと、LLCPだ。
物理レベルの転送がDEPなら、論理レベルの転送はLLCPと言えようか。

アプリから100KBのデータを送信してくれ、という要求が来たとき、DEPで転送できるサイズに小分けにしてくれるのだ。
それだけではない。
自分が持つ転送能力や受信能力をお互いが交換し合い、能力を超えないようにうまいことやるのだ。

 

ちなみに、PCDにアクセスするためのプロトコルというのは、標準があるわけではない。
なのでこの部分は、デバイス依存ということになる。
RC-S956の場合、NFC-DEP仕様の結構な部分をデバイスが吸収してくれてたので、作るのが楽だった。

と思う。
なぜ「思う」なのかというと、送信も受信も自分で作ったので、正しくNFC-DEPが動いているかわからないのだ。
単に、送信したデータが受信できたから動いたんだろうと思っているレベル。
とはいえ、国内で簡単にDEPができる端末ってないんだよなあ。

2011/10/24

android.kernel.gitからgooglesourceに移動したようだ

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がうまくさばけてないとかか。

2011/10/22

SNEPとNPPは構造が異なる

NFC ForumのSNEP-1.0を読んだ。

わかったのは、NPPとはプロトコル構造が異なるということ。
そしてシーケンスも異なり、NPPは送りつけるだけだったのだが、SNEPはリクエストーレスポンス型になっている。

ふむ。

 

SNEPは再送なんかのやり方は規定がない。そこはLLCPに任せているのか(まだLLCP-1.1は読んでない)。
まあ、大ざっぱにいえば「LLCP+SNEP≒FALP」といったところだろうか。
LLCPは携帯電話などの用途に特化しているわけではないので、けっこう複雑だ。
FALPも再送なんかが難しいけど、実装するならまだFALPの方がやりやすいような気がする。
そのうち、LLCPのサブセットが出るのかもね。

Android NDEF Push Protocolについて考える

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対応のおサイフケータイってのもあり得そうだが、どうなんだろうね。
もう覚えてないなぁ。

Android NDEF Push Protocol Specificationを読む

ひどく眠たいので、違うことを書くかもしれんが許しておくれ。


Android NDEF Push Protocol Specification

Version : 1    2011-02-22

2. Overview :

NDEF Push Protocol (NPP) はLLCPの上に載っかるシンプルなプロトコルで、用途は別デバイスへNDEFメッセージをPUSHするためのもので、client→serverの方向。


NPPをサポートするデバイスは、以下のようにあるべし。

  • [MUST]常にNPPサーバを立ち上げておく
  • [MAY]NDEFメッセージがPUSH可能なら、NPPクライアントを起動させる

こうすることで、NPPデバイス間で双方向のNDEF交換ができる。
(サーバ実装は必須で、クライアント実装はおまかせってこと?)

 

3. Data Format

ヘッダとNDEFエントリーから構成されている。
・・・でもヘッダにNDEFエントリーが入っているから、正確にはヘッダだけか。

 

バージョン

メジャーバージョンとマイナーバージョンがあって、今はメジャー0、マイナー1。
ヘッダの"Protocol version"はそれぞれ4bitで、0x01となる。

 

NDEFエントリー

このバージョンではNDEFエントリーは1つだけサポートする。

 

Action code

このバージョンでは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を行うべし。

  1. サービス名"com.android.npp"でLLCPソケットにてサーバと接続
  2. データフォーマットに従って送信
  3. LLCPソケットの切断

クライアントは、NPP pushに失敗したことを表示するために各ステージで失敗をチェックするべし。
エラーによるリトライなどはない。
クライアントは、クライアントが実装しているProtocol versionに従ったAction codeを送信するべし。
(サーバに合わせたりするんじゃないよ、ってことか)

2011/10/21

[nfc]いつの間にかNFC ForumのTechnical Specificationが新しくなっていた

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で前回のものと比較すると、

  • Tag Typeのドキュメント1~3がバージョンアップ
  • Tag Type4は同じファイル名だけど中身が違うみたい
  • LLCPがバージョンアップ

そして・・・

  • SNEPが追加

そう、とうとうSNEPが追加されたのだ。
といっても、私も名前しか知らなかった。しかも教えてもらって知ったので、中身は知らない。
あのとき聞いたSNEPはこういう形になったんだ、という思いだけが残る。


SNEPは「Simple NDEF Exchange Procotol」の略である。

シンプルなNDEF交換プロトコル。

PDFで20ページくらいなので、本文はすくなさそうだ。
が、見るのは週末にしよう。
甘く見て、何度痛い目にあったことか・・・。

 

私の予想では、Android NDEF Push(2011/02/22)が反映されてSNEP(2011/08/31)になったんじゃないか、というところだ。
まだ中身を読んでいないので、今のうちに予想しておかないとねぇ。

2011/10/20

Android NDEF Push?

何気なく記事を読んでいたら、こんなのがあった。
http://www.nfcworld.com/2011/10/19/310778/android-ice-cream-sandwich-adds-nfc-p2p-and-biometric-security/#utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+nfcw+%28NFC+World%29

そこに、こんなリンクが載っていた。
http://www.nfcworld.com/2011/09/29/310293/nfc-forum-publishes-peer-to-peer-communications-specification/

A4で2枚くらいの分量しかないが、読んでない。。
タイトルが「Android NDEF Push Protocol Specification」。
Android NDEF Push ?
なんじゃそりゃ?
どうやら、発表されたAndroid4.0では「Android Beam」なるものがあるらしく、それ関係っぽい。
ふーん。

4.0はIcecream Sandwichか。
「アイスクリーム」というと、榊原郁恵だっけ。あの人の曲が頭に浮かんでくる。
サビか何かで「アイスクリーム ユースクリーム」とかなんとか。
IとYOUをかけてるんだろうが・・・You screamって「あんたは悲鳴を上げる」とかになりそうだ。
その部分しか知らんが、恐るべき歌よ・・・。
まあ、私は歌をほとんど知らんから、別の人だったりするかもしれんがね。

2011/10/16

[bb]いろいろ変えたら、なんか動いた

動かんので、いろいろやってみよう。

デフォルトの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のは動いていたから。

週末の最後に動いたのは、よかったような残念なような。
まあ、いい方にとろう。
よかったよかった。

DVSDKはUbuntu10.04 LTS 32bitしかサポートしない

PSPばかり気にしていたが、DVSDKも気にした方がいいんじゃなかろうか、と急に思った。
kernelがビルドできなかったので、他に頼ろうというわけだ。
http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/dvsdk/DVSDK_4_00/latest/index_FDS.html
現時点での最新版は、上記URLにある。
が、これはOMAP3530をサポートしていない。BeagleBoardのためにはもう1つ前のバージョンが必要だ。
http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/dvsdk/DVSDK_4_00/4_01_00_09/index_FDS.html
ファイルが大きいが、ダウンロードしてインストールさせようとしたところで怒られた。
「Ubuntu10.04 LTS 32bitしかサポートしない」と。
うん、確かにURLにも赤い字で強調してある。
私の環境は、Android用に64bitにしたUbuntu11.04だ。
だから、インストールできない。
QED

[bb]NFS起動についての状況整理

うまくいっていないが、まず状況を整理しよう。


NFSサーバ

Ubuntu11.04+unfs3を使用している。
名前の通り、nfsバージョン3のようである。

 

/etc/exports

/home/xxx/Qt/nfs 192.168.0.22(rw,no_root_squash,no_all_squash,async)


NFSクライアント

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しても同じようにしか見えないのだけどなぁ。

[bb]kernelのブートから切り替わるところを見ていこう

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は、

  1. /sbin/init
  2. /etc/init
  3. /bin/init
  4. /bin/sh

という順で探しに行き、たぶんどれか1つ実行できれば終わりだ。
なければ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が動かずに固まっているか、動いているけどディスプレイに表示されていないかだろう。

整理できなくなってきたので、一旦筆を置こう。

[bb]nfsブートできた!が・・・

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を使っている。
その差が現れたか・・・。
対策は2つしかなく、
  • kernelを2.6.29-rc3-omap1にする
  • 環境を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.

やっぱり、無理矢理はだめなんかね・・・。

[bb]nfsブートがうまくいかないのは、これか?

前々回、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"を追加する必要があるってことか。

これだといいなぁ。
起きたら確認しよう。


普段、2時に寝て7時くらいに起きるから、たまに休日に早く寝るとこんな変な時間に起きてしまうのだ。
ああもったいない・・・。

2011/10/15

[c/c++]NULLチェックの意味

昔から思うのだが、引数のNULLチェックというのは、作っている環境内で「エラーの時はNULLにする」とか「デフォルトはNULLで」とかいう決まりがない限り意味がないよなぁ。
グローバル変数は、だいたいの場合は初期値が0だから、未初期化だとNULLになりそうだから大丈夫だと思う。

でも、じゃあNULLってなんだよ、という気持ちになる。
32bitアドレス系だったとして、0x0000_0000はNGで、0x0000_0001はOKなのか?とか。
0x0000_0000って値は、誰かが代入しない限りはそうならないから、運用でそういうコーディングにしていないと意味がいない、とか。
そもそもdangling pointerには効果がないとかなんとかかんとかある。

なら、ポインタ変数は毎回初期値をNULLにすればいいじゃないか、という話もあろう。
でもさ・・・NULLにするってことは、NULL値を埋める処理が発生するってことやん。
NULLが0なら、そのメモリ分だけ0で埋めなくてはならないのだ。
その手間がもったいないよねぇ。

その辺をチェックする手間を省くために、静的解析ツールがあるのだけど、なんかうまく使ってくれないところがあるのだ。
いや、うまく使ってくれないというのは語弊がある。
コーディング規約などがあって、静的解析ツールのチェックがなるべく作動しないようになっているというべきか。
ツールを100%信用しないというのはいいと思うけど、うーん。。。。

[bb]LUA2-TXがupdate_eth_regs_async()で-22というのはなぜだろう

なぜだろうねぇ。

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) その他の場合

の、どれかというわけだ。
どれだろう・・・。

そしてもう1つ。
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環境に戻して確認するか。

[bb]USB-LANでnfsブートしたい場合には、それしかないのか・・・

http://www.usupi.org/info/koneta.html#nfsroot

えー、それしかないの???

cgrepで検索すると、「No network devices available」はnet/ipv4/ipconfig.c:255にあった。
ic_open_devs()という関数でネットワークデバイスを探している。
これよりも前にデバイスが存在しないと、エラーになるということだ。

では、待たせてみよう。

for_each_netdev()でループしている箇所が2つあるので、2つめの方をリトライさせるようにした。

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 registers
retry : 2
retry : 1
retry : 0
IP-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で非同期にレジスタ変更を行おうとしているのが失敗した、ってことなのかな。
うーむ。

[bb] NFS環境を作りたいがうまくいかない

うまくいかんシリーズです。
前回から続けている、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
CPU: 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::255.255.255.0::eth0 rw root=/dev/nfs nfsroot=192.168.0.2:/home/xxx/Qt/nfs,nolock,rsize=1024,wsize=1024 mpurate=600 omapfb.rotate=1 omapfb.vrfb=y vram=10M omapfb.vram=0:10M omapdss.def_disp=dvi omapfb.mode=dvi:720x480MR-16@60
Booting 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... 516.77 BogoMIPS (lpj=2019328)
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'
usb 1-2: new high speed USB device using ehci-omap and address 2
Advanced Linux Sound Architecture Driver Version 1.0.21.
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
mmc0: new high speed SD card at address b368
mmcblk0: mmc0:b368 SDC   1.85 GiB
mmcblk0: p1
pegasus 1-2.2:1.0: setup Pegasus II specific registers
IP-Config: No network devices available.
pegasus 1-2.2:1.0: eth0, MELCO/BUFFALO LUA2-TX, 00:40:26:c0:bf:af
Looking up port of RPC 100003/2 on 192.168.0.2

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に対してやってるんだけどなあ。
まあ、後で調べよう。

2011/10/12

[bb]Qt環境を作る (2)

液晶モニタを代えたのはいいが、色がまだ慣れないなぁ。
そんなわけで、今回は昨日の調査結果だけまとめる。


まず、まだ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

ここら辺の違いかなぁ。
週末に試してみよう。

2011/10/10

[bb]Qt環境を作る (1)

前準備は整ったということにして、進めていこう。

http://processors.wiki.ti.com/index.php/Building_Qt

今回、OpenGL|ESはやらない。
なんかめんどくさそうだからだ。
まあ、後で必要になったら、やろう。


Building Qt

Step 1

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 C4
Reading boot sector
Loading u-boot.bin from mmc
U-Boot 2010.03 (Feb 20 2011 - 20:15:58)
OMAP3530-GP ES3.1, CPU-OPP2, L3-165MHz, Max clock-720Mhz
OMAP3 Beagle board + LPDDR/NAND
I2C:   ready
DRAM:  256 MB
NAND:  256 MiB
In:    serial
Out:   serial
Err:   serial
Probing for expansion boards, if none are connected you'll see a harmless I2C error.
timed out in wait_for_pin: I2C_STAT=0
I2C read: I/O error
Unrecognized expansion board: 0
Beagle Rev C4
Die ID #1232000400000000040365fa1702200a
Hit any key to stop autoboot:  0
mmc1 is available
reading boot.scr
568 bytes read
Running bootscript from mmc ...
## Executing script at 82000000
mmc1 is available
reading uImage
2381156 bytes read
setenv - set environment variables
Usage:
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.32
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2381092 Bytes =  2.3 MB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK
Starting kernel ...

単にsetenvあたりがおかしいだけみたいだと思ってたのだが、どうもそう簡単な話ではなさそうだ。
bootargsがどうのこうのいう前に、カーネルが始まってない。
カーネルが起動して、ユーザランドに切り替わるあたりまではだいたい進むものだ。
つまり、カーネルがBeagleBoardとあってないということか。

うーん、PSPはBeagleBoard用ってわけじゃないから、ビルドしなおさないとだめなのかな。

[bb]Linuxを動かす (2)

さて、ここからは手探りだ。

今まではAndroid向けに動かしていたので、シェルらしいシェルもない。
busyboxがあればいいのだけど、それではこのスペックにはもったいない気がする。
Qtを動かすのが目的なので、なにかウィンドウシステムがほしいところだ。


そんなわけで、Qtのビルドページを見てみよう。
http://processors.wiki.ti.com/index.php/Building_Qt

Qt Embeddedのソース、それとTIの提供するソフトウェアパッケージのリンクがある。
まあQtはいいとして、わからないのは残りだ。
DVSDK、PSP、GFX SDK。

順に見ていくか。


DVSDK

http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/dvsdk/DVSDK_3_00/latest/index_FDS.html

DVのSDK。
DVは「Digital Video」のようだ。
とりあえずSetup.binをダウンロードして、chmodで+xして実行させた。
すると、インストーラが起動して、自分のhome下にインストールされた。


PSP

http://software-dl.ti.com/dsps/dsps_public_sw/psp/omap3_00/03_00_00_04/index_FDS.html

Platform Support Package。
ここでダウンロードするのは、PSPのSDKみたいだ。


GFX 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ライブラリなんてないだろうから、やっぱり自分で環境を作るしかないか。
気にせず続きを読んでいこう。

ここまでは単に、リンクはここにありますよ、だけで、これらをどうするのかは書かれていなかった。
ちょっと早まってしまったようなので、落ち着こう。


Setting up Target before Qt Build

Qtをビルドする前に、ターゲット環境の設定をしよう。

  • PSPに、MLO、u-boot.bin、uImageとファイルシステムが入っている。
  • Graphics SDK GSGをよんどけ?

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のビルドになる。

ひとまず休憩だ。

[bb]Linuxを動かす (1)

今までも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のカーネルも動いたことだろう。
さて、次は何をしましょうかね。

2011/10/09

[bb]Qtサンプルを試す

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パーティションに置いた。

これが初回動かなくてねぇ。
理由はよくわからずじまい。
もう1回、bzcatしてSDに書き込むところをやり直したらうまくいった。
まあ、気にすまい。

SDを入れて起動すると、Linuxっぽいログイン画面が出てくる。
USBキーボードを最初から挿して起動させると、ちゃんと入力できる。
rootで入る。

デモアプリが入っているので、それを動かす。
パスをREADMEにある場所に移動させ、適当なディレクトリに移動。
たとえばaffinを動かすなら、

$ ./affin -qws -display linuxfb

などとする。
Xなどが動いていれば、アプリ名だけでいいのかも。

よくわからんのが、マウス。
USBマウスを挿してからアプリを起動させると、何かは反応している。
しかしマウスカーソルが表示されないので、よくわからない。

もう1つわからんのが、画面サイズ。
結構なモニタの大きさなんだけど、アプリのウィンドウがそれよりも大きいのだ。
うーん、なんだ?

[a500]フレキの半田付けはあきらめた

まだやってたのか、といわれそうだが、座っている隣にバラバラのA500がいると、落ち着いて酒も飲めやしない(飲むけど)。
開発者はあきらめが悪い方がいい、と思っているが、それは単なる私の性格に過ぎない。
粘り強いのとあきらめが悪いのは、表裏一体だな。
そんなわけで、昨日がんばってみた。



・・・だめだった。
前回、ここまで分解していた。
1
ここまではいだ。
3
全体だと、こんな感じ。
2
2番目の写真で、ピントが合っていないけどフレキの茶色っぽいのが金属の下に潜り込んでいるのがわかるだろうか。
あの先には、フレキがどこかに接続されているはず、とがんばって剥いでいったんだけど、フレキ上に部品が載っていて、それが取れてしまった。
それを貼り付けるのは、私には無理だ・・・。
そして半田付け。
フレキが切れているんだろうから、そこをジャンパーすればいいや、などと思っていたんだけど、私には無理。
まず断線している前後のフレキを薄く削って被覆を剥ぎ、その上に半田付けしてジャンパーする、ということになるのだが、被覆を削るのが怖い。
被覆を光に照らしながら削って、反射の具合で判断しているんだけど、どうにも難しい。
半田付けは難しそうだったので、半田を流し込んでみたのだが・・・載らない。
玉になるし、フラックス使っても載ってくれない。
うーん、液体フラックスなので、広がりすぎているのかな?
ここら辺、技術がないところなのだ。
午後は電気屋さんに行って、導電ペーストみたいなものを探してみよう。
ちょっと遠いんだけど、カホパーツセンターまで歩いて行こう。
秋だから歩かないとね。

2011/10/08

シミュレーティッドアニーリング

最近は疲れているせいか、平日は仕事以外の思考が停止している。
考えるとなると仕事のことになるので、結局のところ思考が止まる。
まあ、そんなもんだ。
そんなわけで、どうでもいいことを書いておこう。



思考といえば、シミュレーション。
組込み現場でも、シミュレーションは大切だ。
実装して動かさないとわからない、というものはある。
あるのだけど、理論的なことは動かす前に推測できなくてはならない。
まあ、だいたい出てくるのはMATLABなのだけど、大御所だけに個人ではちょっと買えない。
個人でなくても、小規模ではちょっと無理だ。
んで、SciLabってのがあったので、動かしているところ。
正直なところ、この分野はよくわからないけど、こういうのがちゃちゃっと動かせると格好がいいではないか。
まあ、動かせるようになれるかどうかわからないけど、もう少しやってみよう。

シミュレーションといえば、思い出すのは「シミュレーティッドアニーリング」。
日本語では「焼き鈍し法」って呼ばれてるんじゃなかったっけ。
といっても、私は内容をよく知らない。すまん。
なんでこの言葉を知っているかというと、学校での研究課題が「遺伝的アルゴリズム」だったからだ。
すごそうな名前だけど、私が知っているやり方はすごく適当。

求めたい値があるけれども、それを得るためのパラメータがたくさんある、という状況を考えてほしい。
数学っぽくいえば、多項式、というのかな。
式と解はあるけど、パラメータが多くてよくわからん、という状況。
正直にプログラムで求めようとすると、for文をそれぞれのパラメータ範囲で行った多重for文ができあがる。
3つパラメータがあって、それぞれ100パターンあるなら、100のループが3つで100万ループだ。
それくらいならまだ現実的だけど、これが16bit値だったり32bit値だったりすると、もういつ終わるかわからん。
なので、この手の解を求めるやり方がいくつかある。
あっさりいえば、「このくらい解に近いんだから、もう解としてしまおう」というような考え方だ。
正解よりも、現実的な解を求めるというやり方だ。
この方法の難しいところは「どこら辺が解としてしまっていい範囲なのか」だろう。
例えば、0となる解が、ある変数の組み合わせで0.00000001となったとしよう。
この値が果たして正統なのか、これよりももっと最適な変数値の組み合わせがあるかどうか、その組み合わせが見つかるかどうかを判定するまでの時間をどのくらいまで許容するか・・・などなど。
これの面白いところは、精度が時代によって変わってくるということだ。
マシンスペックや、計算に要していい時間などの要因がおおきいということ。
例えば先ほどの100万ループ。
もし1ループ1秒かかるなら100万秒、11.5日くらいだ。
でも1ループ1マイクロ秒なら、1秒で終わってしまう。
実際のところ、このくらいのペースで処理速度が向上していっているので、かなりの部分は力業で全パターン計算してしまえばいいような気がする。

とはいっても、今の時点で得られるマシンスペックで最適な解を得なくては意味がない。
そこで生まれた(と私は思っている)のが、遺伝的アルゴリズムだ。



いっておかねばならないが、私は遺伝的アルゴリズム(Genetic Algorithm、以下GA)の権威でもなんでもなく、「私はGAをこんなのだと思ってやってました」という話だから、ちゃんとした人に確認した方がいい。

まず、遺伝子の形を決める。
これは、構造体になってしまうけれども、イメージとしては単なるバイトデータ列だ。
何が入っているかというと、計算に使うパラメータたち。
遺伝子1つに対して、解が1つあると思ってもらえばよいかな。

これを、複数個作成する。
できるだけ数多くだ。
この数は固定とし、最後まで数は維持する。
つまり、解がたくさんある状況。

評価関数があるので、解を突っ込むと、理論値とどれだけ離れているのかという値が求まる。
もちろん、距離が近い方がよい遺伝子となる。

最初は、遺伝子をランダムで作成する。
評価がいいも悪いも気にせず、とにかく決めた数だけ作成する。
んで、評価が一番いいものは上位からいくつか残して、残りを交配させる。
「交配」っていうとものものしいが、ランダムにバイトデータの位置を決め、そこから下を交換するだけ。
構造体のデータ構造などまったく気にせず、データ長からランダムで決めるだけだ。
そして再度評価して、評価の順序を決めて、また交配していく。
これを繰り返していくと、評価がいいものが結構早く求まるのだ。
遺伝子が凝り固まらないよう、ときどきビット単位で「突然変異」を起こすなどして、遺伝子がなるべく流動的になるよう取りはからったりもする。

私がこれを学んだ際、「シミュレーティッドアニーリングでは近似解に落ち込むことがある」と習った。
どういうことかというと、終了条件だ。
細かいことは忘れたが、シミュレーティッドアニーリングもGAも、近似解を求める方法である。
だから、どこで計算をやめるか、という判断が必要になる。
シミュレーティッドアニーリングの場合、徐々に解に近づいていくため、「解の谷」にはまってしまうと、それ以上良い解に行く前に計算を終えてしまうのだ。
あまりうまく説明できないが、解が0のときに+0.001の解が出てしまうと、本当は+0.000001の解があっても計算を終えてしまうという話だ。
まあ、近似解で終わらせるんだから仕方ないんだけどね。

GAの場合、解への近づき方が線形的ではない。
適当な位置でパラメータをよくわからないまま入れ替えているので、ランダムなのだ。
ただ、ある程度の良質な遺伝子が残っていくので、自然と解へ近くなっていく。
線形ではないので、突然解に近寄ったりしていくので「解の谷」にはまりにくい。

そんなのをやってたのだ。
解を求めるためにランダム値を用いるというのは、けっこう抵抗があるものだったんだけど、しばらくやっていると感覚的に受け入れられるようになっていた。
不思議なものである。

これが今の仕事に役立っているかというと、直接にはないな。
でも、考えの柔軟さの幅は広がったと思う。
精密な計算のためにランダムを取り入れる、という考え方だ。
矛盾しているようなところがおもしろい。

2011/10/06

[felica]FeliCa Liteのこと (3)

さて、他に何か書くことがあるだろうか?

私なりの開発の仕方を書き残しておこうか。


最初に買ったのは、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みたいな海外チップにはないのよね。

2011/10/05

RC-S494A

組み込み用の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向けなのかなぁ。

IEEE11073

IEEE11073っていうNFCの規格があるのか?と思ったら、医療機器のデータ関係であった。
見逃していたなぁ。
http://www.atmarkit.co.jp/news/200709/13/health.html

[felica]FeliCa Liteのこと (2)

うろおぼえで書く、FeliCa Liteのこと。
第2弾だ。
まさか続くとは誰も思っていなかっただろう。


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レジスタを書き換えるときは、だいたい1次発行するときで、1次発行するとNDEF対応ビットが固定化されてしまう。
SONYさんから出ている、FeliCa LiteをNDEF対応するツールがあるが、あれは確か0次発行状態のカードを1次発行するものだったと思う。

2011/10/04

[felica]FeliCa Liteのこと (1)

最近、忙しくて調べながら書く余裕がない。
なので、記憶に頼って書くことにする。

記憶に頼って書けそうなことと言えば、最近はFeliCa Liteのことくらいだ。


FeliCa Liteは、FeliCaの簡易仕様版みたいなところがある。
データについては暗号などのセキュリティ機能をカード側では持っていない。
3DESで計算した結果は取得できるので、それを使った「改ざんチェック」が行えるだけである。
その改ざんチェックも、カードデータが読み取る側が行う必要がある。
これが「片側認証」と言われるセキュリティである。

 

よって、用途として一番よいのは、データブロックには重要なデータを書かず、会員証のようなカード自身の正当性を確認する使い方ではないかと思う。
スイッチサイエンス社で、1枚350円くらいだ。

ただ、カード単体の値段で見ると、たぶんMifareの方が安いんじゃないかと思う。
UltraLightは64byteくらいのデータしか持てないけど、大量に仕入れたらかなり安くなりそうだ。
次世代のFeliCa Liteが出たら、もっと安くなってよいかも。

 

FeliCa Liteのデータは、200byteくらいだ。
ブロック数が13か14か忘れてしまった(でも調べない)。
1ブロックだけ、回数券風にカウントダウンするデータブロックがある。
今の値より小さな値しか書き込めなさそうなので、未だに試したことはない。