[q5]SmartQ5へAndroid2.3.4を載せようとしているが、うまくいかん。

はい、うまくいかんシリーズです。
SmartQ5にAndroid2.3.4を載せようとしているところ。
ビルドなんかは通るのだが、動かん。

どこかというと、init中。
kernelも起動し、initも動いてinit.rcを読んで動こうとしているのだが、ファイルがいろいろと見つからない。
いろいろとというよりも、/以外見えてないんじゃなかろうか？というところ。
SDブート式にすれば今までの要領でやれそうなんだけど、ここはせっかくなのでiNANDに書き込みたい。

そもそも、iNANDってどういう風に見えてるんだろう？
SDインターフェースでアクセスするようなので、

mmc0: host does not support reading read-only switch. assuming write-enable.
mmc0: new high speed SD card at address d555
mmcblk0: mmc0:d555 ST01G 1003264KiB
 mmcblk0: p1 p2 p3

これかな。

まあ、今週も忙しくて見る暇はないだろうから、来週だな。
あーー、今も雨が降っているので、今週は憂鬱な週になりそうだ。。。

[q5]SmartQ5を復旧させる

SmartQ5のソースが入手できることがわかったので、repoで取ってきた。
ビルドできるのはだいたい確認できたので、そのままAndroid2.3.4を突っ込んでみようと考えた。

そこまではよかったのだが、ビルドの確認が「だいたい」すぎた。。
最後に「OK」みたいなのが出たから安心していたが、kernelのビルドができていなかった。
しかし私は安心しきっていたので、そのままSmartQ5にインストールさせてしまった。

そして・・・起動しなくなった・・・。

さて、復旧させますか。

---

SmartQ5 debug serial port

まずはこちらを見て、デバッグ用のシリアルポートを確保。
別件で購入していたレベルコンバータ兼USBシリアルを接続。

そうすると、Qiというブートローダが起動していることが確認できた。
まったく死んでしまったわけではないようだ。
よしよし。



そういえば、SmartQ5掲示板にファームウェアアップデートに失敗したときのことが書かれていた。

1. PanasonicのSDフォーマッタでフォーマット。といいつつ私はHPのフォーマッタを使ったが。
2. SD Card Update Toolで何か知らんが書き込む。
3. そのSDカードをSmartQ5に入れ、AC電源を挿し、+と-の間にあるボタンを押したままリセット。
4. かなり待たないといかんが、待ってるといつものファームウェアアップデート画面が出てくる。

2は、やらなくていいかも。
わからないのでやってみたけどね。

AccessoryChatの使い方

こんにちは。

最近、USB Accessory機能が追加されましたが、Arduinoとか持ってないので他の実現手段を探していました。
一番手軽そうなのが、Accessory Chatアプリを動かす方法だったので、紹介します。
ただ、自作の環境でしか試せていないので、他でも使えるかどうか分かりません。


AccessoryChat

◆どういうもの？
USB Accessory機能のテスト用アプリ。
通信相手は、Linuxで動くPC。
なので、Linuxが動くPCが必要になります。
VMwareでやれるかどうかは、わかりません。

◆環境
Android Platform(2.3.4)の開発環境一式がたぶん必要です。
どこからかダウンロードしてください。

◆ビルド
Androidアプリと、Linuxアプリの２つがあります。

$ cd frameworks/base/libs/usb/tests/AccessoryChat
$ mm
$ cd accessorychat
$ mm

最初のmmでAndroidアプリが、次のmmでLinuxアプリがビルドされます。
Androidアプリは、out/target/product/(各自の環境)/data/app/AccessoryChat.apk。
Linuxアプリは、out/host/linux-x86/bin/accessorychat。

◆使い方
Android端末の方にはアプリをインストールしておきます。
Linux側でaccessorychatを起動させておき、Android側にUSB Bを挿したUSBケーブルをPCに挿します。
そうすると、うまくいけばAndroid側が自動的にAccessoryChatを起動させようとします。

接続がきちんとできれば、Android側から送信した文字列がLinux側に表示されるし、Linux側が入力した文字がAndroid側に表示されます。

◆解説
ポイントは、accessorychatアプリ。
この人が、Android Accessory Protocolをkernelとやりとりしています。
README.txtによると、Android側で動かすこともできるらしいです(hostサポート時)。

動きについては、今までの記事を参考にしてください。

[felica]PUSH端末

今週、Googleプレイスのフィールドテストがあったようだ。
http://www.itmedia.co.jp/news/articles/1106/24/news017.html


かざすとレビューができる、くらいしか書かれていないので、実際に何が行われているかわからない。
が、twitterで「R/Wが電池かいな？」ということが書かれていた。

そうならば、これはPUSH端末だ。
例えば、こんなの。
http://www.usc-sbc.com/navi/index.htm

R/Wかと言われると、PUSH専用なので「違う」ということになる。
が、PUSHする機能はInitiatorコマンドなので、R/W機能と言えなくもないか。
まあ、私も仕事でしかものを見たことがないんだけどね。

[nfc]ISO-DEPとは？

コメントをいただいたので、久しぶりにNFCの資料を眺めている。
Nexus SとPN532でDEPできるか？というもの。

Nexus Sといえば、Android 2.3.4。
Android 2.3.4といえば、IsoDep。
IsoDepはISO 14443-4。
NFC Forum的にはISO-DEPもNFC-DEP、すなわちISO 18092のDEPもある。
手近に資料があるので、NFC Forumのドキュメントから見ていこう。


-- NFC Forum --

ISO-DEPは、Type 4AかType 4Bタグを使用する。
Type 1は、NFC-A。でもCRC_B。
Type 2も、NFC-A。こっちはCRC_A。
Type-3は、NFC-F。あれ、Listen Modeはoptionalなんだ。。。
Type-4Aは、NFC-Aで、Listen Modeはoptional。
Type-4Bは、NFC-Bで、Listen Modeはoptional。

今までR/W周りをやってきてわかったのは、R/Wコマンド1発でいろいろとパケットをやりとりしていること。
それと、パケットの中身もうまいこと作ってくれていること。
CRCやDIDなんかは、上位層は気にしなくてよかったからな。
なので、RFパケットのところはあまり深く見なくても済む。


-- ISO 14443-4 --

ネットで、ISO 14443-4ドキュメントが出てきた。
いいんだろうか。。。
詳細な説明は見ない。それは前述した通りだ。
ただ、用語は把握しておいた方がよい。
DEP、という言葉は使われていないのだ。
「Half-duplex block transmission」とか「chaining mechanism」とか。
そういった言葉がデータ交換周りで使われている。

これを基礎知識として、PN533のドキュメントを読んでみよう。


-- PN533 --

ここでは「ISO/IEC14443-4 chaining mechanism」と「DEP chaining mechanism」という言葉が出てきている。
chainingというのは、大きいデータを複数パケットに分割するやり方、みたいなものだと把握している。
なので、これは送信した後の話だ。
送信するパケット自体の話は、そのシーケンスを見るとよい。

ISO14443-4 chaining mechanismのシーケンス例として、PN533(Initiator)とISO 14443-4 PICC間のものが描かれている。
PICCはProximity IC Cardのことだが、おそらくTargetと同じ意味だろう。
InitiatorがInListPassiveTargetでポーリングすると、相手からSEL_REQの応答SEL_RESとして「ISO14443-4 compliant」が返ってくるとなっている。

では、SEL_RESを見てみよう。
NFC Forumのドキュメントを見ると、SEL_RESのbit7, 6で判断できるようだ(bit8～1)。
・00 : Type2 Tag
・01 : Type 4A Tag
・10 : NFC-DEP
・11 : Type 4A TagとNFC-DEP
つまり、bit6=1であればISO-DEPが可能ということになる。
このSEL_RESは、ISO18092のものを拡張してある。こちらはbit7をチェックするだけになっている。

シーケンスの続きでは、InListPassiveTargetのあとはInDataExchangeになっている。
では、とInDataExchangeの詳細を読むと、ああ、説明が全部書いてあった。
SetParametersも一緒にやってやらんといかんかも。


そんなわけで、R/Wから見たISO-DEPは、

• PN533ではInDataExchangeでDEP Initiator側になれるはず
• Initiatorになるなら、InListPassiveTargetでSEL_RESを見るとよい
• TgInitAsTargetでDEP Target側にもなれるはず

というところでしょうかね。

[nfc]ISO 18092

ISO 18092は、通称「NFCIP-1」と呼ばれている。
あるいは逆かもしれないが、その日本語版がJIS X 5211。
PDFはJISのホームページから見ることができる。

FeliCaはISO 18092で国際規格になっている、といわれるが、FeliCaというよりもNFC ForumでいうところのNFC-Fの部分が規格化されているといった方が正しいと思う。
ISO 18092を製品化しました、の例がFeliCaという見方かな。
ソフト的にいうなら、ISO 18092を基底クラスに持った派生クラスがFeliCa、と。

ただ、ISO 18092には106kbpsの規格も書かれている。
そう、NFC ForumでいうところのNFC-Aだ。
いわゆる「Type-A」で、その製品例がMifare。

よくわからないのが、なぜType-AはISO 18092にもISO 14443にも現れたのか、だ。
http://www.atmarkit.co.jp/frfid/special/5minic/04.html
こちらを読むと、ISO 14443ではだめだったFeliCaが、Philipsと組んでNFCとして提案、と書かれている。
Philipsといえば、もちろんType-A。
だから、Type-AとFeliCaの無線部分が規格になったということか。


残ったのは、Secure Element。
メモリ部分だ。
この部分がおのおの異なって製品になると考えてもよさそうだ。
Mifareは、SWPで外部と通信するようにしているみたいだ。
FeliCaは非公開だが、とりあえず別チップにはなっている(少なくとも今販売されているのはそうだろう)。

SWPになると何がいいかというと、SWPに対応したチップが使えるということだ。
また、SWPというプロトコルでやりとりすればいいので、NFC部分がメーカー依存にならずに済むという安心感のようなものがある。
まあ、逆も然りで、SWPでアクセスできてしまうのでセキュリティ的な危険は増すのかも。
残念ながら、私はSWPをよく知らないのだ。。。

ちょっと検索してみたが、USIMとかUSATとか、避けてきた単語が・・・。
そんなわけで、このまま避け続けたいと思います。


ふっ、と、AES対応はSWP対応の前準備ではないか？と思った。
FeliCaのSecureElementを守るためには、3DESでは足りないと判断したのかもしれない。

[qt]Qt Creatorでどこら辺ができるか(2011/06)

数年前の私は、Qt Designerを使いたがらない方だった。
理由は、デザインをコードで書くよりも遅くなるはずだからだ。
私が扱ってきたソフトでは、ユーザが画面をリサイズさせることはなく、画面の配置は常に一定でよい。
そうなると、わざわざリサイズに対応していたり、自動的に画面部品の位置を調整してくれるような機能はもったいない。
ディスクを圧迫するし、なにより画面の表示が遅くなる、と。

しかし、時代は流れた。
Qtで画面を表示するような実行環境であれば、その程度のパワーはあまり問題にならなさそうだ。
それよりも、画面レイアウトを別の人にお願いできる方がありがたい。

そんなわけで、Qt Creatorのデザイナでどこら辺ができるのか見てみた。
今のQt Creatorが、というよりも、今の私が、という意味合いが大きい。
まだよくわかっていないので、認識が違うかもしれん。

---

画像がでかいが、まあいいや。。。

部品(Widget)を置いたり、並べたりは、当然ながらできる。
WidgetのまとまりをLayoutで管理できるのだが、これは置いた後でも設定できる。
どちらかというと、置いた後でやった方がやりやすい。
先にLayoutを配置してその中にWidgetを突っ込んでいくのは、けっこう大変だった。

ボタンのシグナルと規定のスロットを接続することもできる。
これは「シグナル/スロット エディタ」でやれた。
シグナルを新たなスロットに接続することもできる。
これは「スロットへ移動」でやるようだ。

新しいシグナルの作成が、はっきりしない。
「シグナル/スロットを変更」ではスロットとシグナルが出てきて、追加ができる。
できるのだが、引数がよくわからん。
私が持っている本「入門Qt4プログラミング」では、引数にconstとか&とかを使っているのだが、このダイアログではスペースや&が入力できないのだ。

---

今の私のレベルでは、ここまでだ。
全然使いこなせてないなぁ。

まあ、慌てずにやっていこう。

[qt]デバッグ開始するとエラーになったが、解決できた

一難去ってまた一難。
今度はデバッグ開始するとSegmentation Faultで落ちてしまう。
デバッグ版の開始ではなく、デバッグ開始。
つまり、ブレークポイントとかで止まってほしいの時の開始ですな。

今回よかったのは、デバッグモードでの起動だったので、落ちた箇所がわかることだ。
落ちたのは、c:\WINDOWS\system32\guard32.dll。
これで検索すると、いくつか見つかった。
「別の名前にリネームしろ」というのが解決方法だった。
どうやら、FirewallソフトにCOMODO Firewallを使っている人に見られる現象のようだ。

そんなんでいいのか？と思いつつやってみると、確かに問題なくなった。
始めるまでが大変ですなぁ。

[qt]ビルドできるようになった

QtSDKでビルドできるようになった。
ただ。。。何をしたのが直接よかったのかがわからない。

環境変数PATHに、自分でも気付いていないものが関係しているものが含まれているかもしれないので、動作に影響がなさそうな範囲で削除。
TortoiseGitやTortoiseSVNなんかは残したが、doxygenやgraphvizなどは消した。

そこで試しておけばよかったのだが、もう１つやってしまった。
レジストリクリーナーだ。
フリーのレジストリクリーナーがインストールされていたので、それを実行。
私のところでは、Wise Registry Cleaner4が入っていた。
１つずつ見ていくのも面倒なので、自動クリーンをやった。

そしたら、ビルドできるようになった。
Qt Creatorでもコマンドプロンプトでもどっちでもだ。
他には操作してないと思うけどな。。。

気になったのでPATHを戻してみたが、ビルドできる。
ということは、レジストリクリーナーが効いたってことなのか。
今までレジストリクリーナーで顕著な効果が出たことがなかったので「絶対にこれだ」と断言できない。
ビルドできない場合はお試しください、というくらいで。

[qt]まだビルドできない

デスクトップPCのPATHからmingw, cygwinっぽいパスを外した状態でQtSDKを新規インストールし直した。
やり方はノートPCと同じ。
インストールして、同じようにExamplesを動かしたが・・・・やはり同じエラーが出る。

しかし、今回はMakefileはrmではなくdelを使うようになっていた。
やはり何かしらの情報を使っていたのだろう。
それはいいのだが、他に何があるのだろうか？

まずはウイルス対策ソフトを削除してやってみた。
デスクトップPCはavast!6を、ノートPCはAviraを使っている。
しかし変わらず。。

procmonで見てみると、実行するためのbatファイルをDocuments and Settings以下のTempに作成するのだが、そのスレッドがファイルを作ってExitThreadした直後にmingw32-makeがProcessExitして、エラーを出している。
エラー番号は255で、QtCreatorも同じことを言ってた。
mingw32-makeが死んだ後は、svchost.exeがあれこれ見に行っているが、これはなんとなく関係なさそうだ。

なんでbatファイル生成後に死んでいるのかがよくわからない。
うーむ、週末は何もしないといってはみたものの、この状況は気持ち悪いなぁ。