2011/05/31

今回のno vmaはアクセス権の問題ではないようだ

no vmaについて少し検索すると、アクセス権が足りてない、というような記述がちょっとあった。
では、ちょっと試してみよう。

$ chmod 0777 -R data

だめ。

$ chmod 0777 *

だめ。

$ chmod -R 0777 *

だめ。

というわけで、今回はアクセス権の問題ではないようだ。
次いってみよう。

ASHMEMがないんじゃないの、というのもあったが、それは大丈夫だ。

ashmem: initialized

no vmaなどといわれる

DisplayLinkの件は、適当に片付けることにした。
「どうせデフォルトで/dev/graphics/fb0を使ってるんだったら、fb1にすればいいじゃないの」ということだ(なぜ女言葉・・・)。
copybitとかないので、ここだけでよさそうだ。

hardware/libhardware/modules/gralloc/framebuffer.cpp

この中で、device_template[]を使ってフレームバッファのデバイス名を探すところがあるのだが、0を使っているので1にするだけ。
とりあえずこれで、起動アニメーションが出てきた。
よかったよかった。。。あれ?

binder: 904: binder_alloc_buf, no vma
binder: 915:921 transaction failed 29201, size 64-0

起動アニメーションを再起動している。。。
メモリが足りない系統っぽいが、fb1にすることで何かやってしまったのかな?

せっかくコメントがついた日くらいはがんばりたいところだが、緊急目標として「しばらくは1時半までに寝る」を設定してしまったので、寝よう。
昼間が眠いのよ。。。

2011/05/30

同じバージョンなのにいままでのと全然違う

今まで使っていたkernelと、rowboatのkernel。
バージョンはどちらも2.6.32。
ならば移植は簡単だろうと思っていたのだが・・全然だめだ。

drivers/usbを置きかえ、コンパイルエラー。
では、とinclude/linux/usbも置きかえ、やっぱりコンパイルエラー。
あちこちつぎはぎして、今度はttyエラー。
「これではビルドが通っても正しく動かないかも」と思うような修正をしたら、今度はi2cが。
ヘッダのファイル名が変わってるし、APIも追加されてる。。。

というところで、今一息ついたところだ。
同じものでは・・・ないのか?
違うといえば、バージョンも正確には、2.6.32.9、となっている。
この「.9」がこの差を生んでいるのだろうか。

うーん、我慢強い方だと思っていた私だが、さすがに音を上げそうだ。
rowboatベースでDisplayLinkを動かせるようにした方が早いのかもしれない。
試しにやってみるか。

kernelを変更して困ったことが2つ

さて、adbも動いたし、あとはAPPを載せて動作確認するだけ、と思ったが、そうはいかなかった。
今まで使用していたkernelからrowboatのkernelになったことで、困ったことが2つ出てきたのだ。

1つは、mediaserverが再起動を繰り返すようになったこと。
差分がどこにあるか分からないけど、init.rcとかasound.confあたりで済めばありがたい。
それにまあ、再起動しているだけなので、無視していればいい、ということもある。

問題は2つめだ。
DisplayLink側に表示してくれない。
起動すると画面が1色で塗りつぶされているので、ドライバの初期化は呼ばれている。
しかし、そこから変化なし。
おそらく、強制的にDVI側に出しているんじゃないだろうか。
まいったなぁ。。。


TIのAndroid環境は以下の特長があるとかかれている。
The following features from previous release are provided:
  • Fastboot
  • WLAN (WL1271) on AM37x EVM
  • NAND UBIFS booting
  • UI and video on S-video
  • Adobe Flash 10
  • USB Mass Storage
  • Audio Record feature in Android
  • Bluetooth connectivity for OPP, A2DP profiles
  • Camera Image capture on Beagle XM
  • Performance measurements using RowboPERF, 0xbench and rowboatbench
  • Media clips for Audio, Video and JPEG
  • Keypad support on AM35x EVM
  • Hardware accelerated dynamic rotation for Video pipeline.

このあたりが影響を受けているような気がする。
それならいっそのこと、Android環境もTIのものに置き換えればいいのだがちょっと気力が沸かない。

TIの環境が劣っているとか、そんなことはないのだ。
むしろ優れている。
いやがっているのは、せっかくgithubで作ってきた環境がつかえなくなること。
OESFさんの環境をcloneしているのを、rowboatさんので置きかえていけばいいんだろうけど、repoでとってくるタイプになるので、全部cloneしていくのがめんどくさい。

うーん、どうしたものか。。。

2011/05/29

あっさりadbが動いた。。

TIのAndroid環境、しかもGingerbreadだ。
環境としては、1.0と2.0があるけど、BeagleBoard(ノーマル)は1.0だ。

ダウンロードできるものはいろいろあるのだが、私が欲しいのはkernelだけ。
だけなのだが、よくわからないのでTI_Android_GingerBread_2_3_Sources.tar.gzをまるまるダウンロードした。
解凍させてlsで見ても、ファイルがなにもない。。。
127GBもダウンロードしたのに!と思ったら、「.repo」ができていた。
これをrepo syncして、最新版もとってきつつファイルにした。
これはこれで、けっこう時間がかかった。

kernelは、2.6.32。
私はext4を使っているので、そこだけチェックしてビルド。
uImageを入れ替えると。。。動いた。
まあ、動くのは当たり前として、adbだ。
USBを挿すとPCのほうは。。。

[40495.340367] usb 1-4.4: new high speed USB device using ehci_hcd and address 61

おっ、エラーっぽいのが出ない。
lsusbすると、

Bus 001 Device 061: ID 18d1:9018 Google Inc.

おおっ、それっぽい。いや、ほとんど間違いない。
では、最後に、

$ adb kill-server
$ adb start-server
$ adb devices
List of devices attached
20100720    device

あっさりですな。。。
どうやら、rowboatベースらしい。
そうか、そっちを見ていくのがいいんですな。
ありがとうみなさん、また一つ勉強しました。

g_etherはよかったが、g_androidはだめだった

g_android(Gadget Android)はだめだった。
しかし、今回はg_ether(Gadget Ether)との比較ができる。


<7>twl4030_usb twl4030_usb: HW_CONDITIONS 0xd0/208; link 2
<7>musb_interrupt 1536: ** IRQ peripheral usb0001 tx0000 rx0000
<7>musb_stage2_irq 816: SUSPEND (b_idle) devctl 99 power e0
<7>musb_stage2_irq 820: state (1) active (0)
<7>musb_interrupt 1536: ** IRQ peripheral usb0004 tx0000 rx0000
<7>musb_stage0_irq 385: <== Power=f0, DevCtl=99, int_usb=0x4
<7>musb_stage0_irq 647: BUS RESET as b_idle
<7>musb_g_reset 1995: <== B-Device addr=0 driver 'android_usb'
<7>musb_interrupt 1536: ** IRQ peripheral usb0008 tx0001 rx0000
<7>musb_g_ep0_irq 628: csr 0001, count 8, myaddr 0, ep0stage setup
<7>musb_read_fifo 202: RX ep0 fifo fa0ab020 count 8 buf cfa55da4
<7>musb_read_setup 562: SETUP req80.06 v0100 i0000 l64
<7>musb_g_ep0_irq 811: handled 0, csr 0001, ep0stage in
<7>musb_g_ep0_queue 917: queue to ep0 (OUT/RX), length=18
<7>musb_write_fifo 164: TX ep0 fifo fa0ab020 count 18 buf cf8ccc00
<7>musb_g_giveback 144: ep0 done request cf8bd6c0,  18/18
<7>musb_interrupt 1536: ** IRQ peripheral usb0008 tx0001 rx0000
<7>musb_g_ep0_irq 628: csr 0000, count 0, myaddr 0, ep0stage out/status
<7>musb_interrupt 1536: ** IRQ peripheral usb0000 tx0001 rx0000
<7>musb_g_ep0_irq 628: csr 0000, count 0, myaddr 0, ep0stage idle
<7>musb_interrupt 1536: ** IRQ peripheral usb000c tx0000 rx0000
<7>musb_stage0_irq 385: <== Power=f0, DevCtl=99, int_usb=0xc
<7>musb_stage0_irq 647: BUS RESET as b_peripheral
<7>musb_g_reset 1995: <== B-Device addr=0 driver 'android_usb'
<7>musb_g_disconnect 1939: devctl 99

ここまでは、一緒。
では、次。

<7>musb_interrupt 1536: ** IRQ peripheral usb0008 tx0001 rx0000
<7>musb_g_ep0_irq 628: csr 0001, count 8, myaddr 0, ep0stage setup
<7>musb_read_fifo 202: RX ep0 fifo fa0ab020 count 8 buf cfa55d0c
<7>musb_read_setup 562: SETUP req00.05 v002c i0000 l0
<7>service_zero_data_request 237: bRequest (05)
<7>musb_g_ep0_irq 811: handled 1, csr 0001, ep0stage in/status
<7>musb_interrupt 1536: ** IRQ peripheral usb0008 tx0001 rx0000
<7>musb_g_ep0_irq 628: csr 0000, count 0, myaddr 0, ep0stage in/status

あら、一緒ですな。
アドレスはもらったようだ。


<7>musb_interrupt 1536: ** IRQ peripheral usb0008 tx0001 rx0000
<7>musb_g_ep0_irq 628: csr 0001, count 8, myaddr 44, ep0stage idle
<7>musb_read_fifo 202: RX ep0 fifo fa0ab020 count 8 buf cfaffcac
<7>musb_read_setup 562: SETUP req80.06 v0100 i0000 l18
<7>musb_g_ep0_irq 811: handled 0, csr 0001, ep0stage in
<7>musb_g_ep0_queue 917: queue to ep0 (OUT/RX), length=18
<7>musb_write_fifo 164: TX ep0 fifo fa0ab020 count 18 buf cf8ccc00
<7>musb_g_giveback 144: ep0 done request cf8bd6c0,  18/18
<7>musb_interrupt 1536: ** IRQ peripheral usb0008 tx0001 rx0000
<7>musb_g_ep0_irq 628: csr 0000, count 0, myaddr 44, ep0stage out/status
<7>musb_interrupt 1536: ** IRQ peripheral usb0000 tx0001 rx0000
<7>musb_g_ep0_irq 628: csr 0000, count 0, myaddr 44, ep0stage idle

明確な違いはない。
そして次で終わる。

<7>musb_interrupt 1536: ** IRQ peripheral usb0009 tx0000 rx0000
<7>musb_stage2_irq 816: SUSPEND (b_peripheral) devctl 99 power f0
<7>musb_stage2_irq 820: state (3) active (1)
<7>musb_g_suspend 1903: devctl 99
<7>android_usb gadget: suspend composite
<7>musb_stage2_irq 843: otg (0) hnp(0)

PC側は、こうなった。

[22707.780482] usb 1-4.4: new high speed USB device using ehci_hcd and address 44
[22707.890447] usb 1-4.4: no configurations
[22707.890457] usb 1-4.4: can't read configurations, error -22
[22707.980467] usb 1-4.4: new high speed USB device using ehci_hcd and address 45
[22708.090434] usb 1-4.4: no configurations
[22708.090444] usb 1-4.4: can't read configurations, error -22
[22708.180455] usb 1-4.4: new high speed USB device using ehci_hcd and address 46
[22708.210655] usb 1-4.4: no configurations
[22708.210664] usb 1-4.4: can't read configurations, error -22
[22708.300446] usb 1-4.4: new high speed USB device using ehci_hcd and address 47
[22708.330649] usb 1-4.4: no configurations
[22708.330658] usb 1-4.4: can't read configurations, error -22
[22708.340143] hub 1-4:1.0: unable to enumerate USB device on port 4

リトライしてあきらめた、というところだろう。
違いは、g_etherかg_androidかなので、g_androidの対応が足りていないということか。
あるいは、その下のFunctionか。

<6>f_adb init
<6>android_register_function adb

として、今回はADBを登録していた。
うーん、よくわからないなぁ。
ADBなんかも、BeagleBoard用に手を加えないといけないとか?


などと思って検索していると、TIのAndroid環境があった。
そんなものが!
・・・いや、以前にも目にしたことがあるのだが「自分でやるんだ!」と切り捨てていたのだ。
ああ、私にはまだ先生が必要なのですな。

OTGじゃなくてPeripheralでよいのでは?

BeagleBoardのDisgnostic Kernelを入れると、PCはBeagleBoardをEtherカードとして認識してくれる。
そのソースがgitoriousにあるので、自分でビルドして確かめようとした。

しかし・・・ビルドが通らない・・・。
初出の変数があるのだが、それがどっからどうすべきものかがわからず。。。
それはあきらめ、defconfigを見ることにした。

そうするとですな、OTGはOFFになっているのだ。
Gadgetは有効になってて、MUSBも有効にしてある。
ああ、こういう方法もあるんだ。。。。。

最近、EHCIポートが使えることに気づいたので、OTGポートはPeripheral専用にしてしまって問題ないのだ。
ではやってみよう、と設定をいじっていたが、なかなかうまくいかん。
kernelのバージョンによって、設定が少しずつ違っているのだ。
それに、BeagleBoardは基板の版によってハードウェア構成が異なるため、ある設定では動いてもある設定では動かない、ということがあるように思うのだ(私はC4版)。
特にUSB周りは変更がいろいろとあったようなので、混乱している。

今さっき、ようやくPCが認識してくれた。

Bus 001 Device 043: ID 0525:a4a2 Netchip Technology, Inc. Linux-USB Ethernet/RNDIS Gadget

いきなりAndroidのではわからないので、Diagnostic Kernelでも動いていたネットワークのGadgetにしてみたのだ。
おとなしく書いているが、非常にうれしい。

さて、BeagleBoard側のログだ。
まず、挿してから認識後のRESETまで。
そうなのだ、やはりRESETはしているのだ。

<7>twl4030_usb twl4030_usb: HW_CONDITIONS 0xd0/208; link 2
<7>musb_interrupt 1536: ** IRQ peripheral usb0001 tx0000 rx0000
<7>musb_stage2_irq 816: SUSPEND (b_idle) devctl 99 power e0
<7>musb_stage2_irq 820: state (1) active (0)
<7>musb_interrupt 1536: ** IRQ peripheral usb0004 tx0000 rx0000
<7>musb_stage0_irq 385: <== Power=f0, DevCtl=99, int_usb=0x4
<7>musb_stage0_irq 647: BUS RESET as b_idle
<7>musb_g_reset 1995: <== B-Device addr=0 driver 'g_ether'
<7>musb_interrupt 1536: ** IRQ peripheral usb0008 tx0001 rx0000
<7>musb_g_ep0_irq 628: csr 0001, count 8, myaddr 0, ep0stage setup
<7>musb_read_fifo 202: RX ep0 fifo fa0ab020 count 8 buf cfa95f0c
<7>musb_read_setup 562: SETUP req80.06 v0100 i0000 l64
<7>musb_g_ep0_irq 811: handled 0, csr 0001, ep0stage in
<7>musb_g_ep0_queue 917: queue to ep0 (OUT/RX), length=18
<7>musb_write_fifo 164: TX ep0 fifo fa0ab020 count 18 buf cf8aec00
<7>musb_g_giveback 144: ep0 done request cf8be6c0,  18/18
<7>musb_interrupt 1536: ** IRQ peripheral usb0008 tx0001 rx0000
<7>musb_g_ep0_irq 628: csr 0000, count 0, myaddr 0, ep0stage out/status
<7>musb_interrupt 1536: ** IRQ peripheral usb0000 tx0001 rx0000
<7>musb_g_ep0_irq 628: csr 0000, count 0, myaddr 0, ep0stage idle
<7>musb_interrupt 1536: ** IRQ peripheral usb000c tx0000 rx0000
<7>musb_stage0_irq 385: <== Power=f0, DevCtl=99, int_usb=0xc
<7>musb_stage0_irq 647: BUS RESET as b_peripheral
<7>musb_g_reset 1995: <== B-Device addr=0 driver 'g_ether'
<7>musb_g_disconnect 1939: devctl 99

最初にRESETしてるのはいいとして、今回も接続後にRESETしているのだ。
ep0stageで、setupステージ後のout/statusステージで何も送信していなさそうなのも、同じ。
前回と違うのは、ここからリトライにならず、次に進んだこと。
次のログを載せよう。

<7>musb_interrupt 1536: ** IRQ peripheral usb0008 tx0001 rx0000
<7>musb_g_ep0_irq 628: csr 0001, count 8, myaddr 0, ep0stage setup
<7>musb_read_fifo 202: RX ep0 fifo fa0ab020 count 8 buf cfa95f0c
<7>musb_read_setup 562: SETUP req00.05 v002b i0000 l0
<7>service_zero_data_request 237: bRequest (05)
<7>musb_g_ep0_irq 811: handled 1, csr 0001, ep0stage in/status
<7>musb_interrupt 1536: ** IRQ peripheral usb0008 tx0001 rx0000
<7>musb_g_ep0_irq 628: csr 0000, count 0, myaddr 0, ep0stage in/status


またSETUPから始まるのか、と思わせたが、in/statusステージになっている。
前はreq80.06なので、GET_DESCRIPTOR。
ここはreq00.05なので、SET_ADDRESS。
そう、ようやくアドレスが取得できたのだ。

もう2つ先まで載せよう。

<7>musb_interrupt 1536: ** IRQ peripheral usb0008 tx0001 rx0000
<7>musb_g_ep0_irq 628: csr 0001, count 8, myaddr 43, ep0stage idle
<7>musb_read_fifo 202: RX ep0 fifo fa0ab020 count 8 buf cfa95f0c
<7>musb_read_setup 562: SETUP req80.06 v0100 i0000 l18
<7>musb_g_ep0_irq 811: handled 0, csr 0001, ep0stage in
<7>musb_g_ep0_queue 917: queue to ep0 (OUT/RX), length=18
<7>musb_write_fifo 164: TX ep0 fifo fa0ab020 count 18 buf cf8aec00
<7>musb_g_giveback 144: ep0 done request cf8be6c0,  18/18
<7>musb_interrupt 1536: ** IRQ peripheral usb0008 tx0001 rx0000
<7>musb_g_ep0_irq 628: csr 0000, count 0, myaddr 43, ep0stage out/status
<7>musb_interrupt 1536: ** IRQ peripheral usb0000 tx0001 rx0000
<7>musb_g_ep0_irq 628: csr 0000, count 0, myaddr 43, ep0stage idle



<7>musb_interrupt 1536: ** IRQ peripheral usb0008 tx0001 rx0000
<7>musb_g_ep0_irq 628: csr 0001, count 8, myaddr 43, ep0stage setup
<7>musb_read_fifo 202: RX ep0 fifo fa0ab020 count 8 buf cf82bd34
<7>musb_read_setup 562: SETUP req80.06 v0200 i0000 l9
<7>musb_g_ep0_irq 811: handled 0, csr 0001, ep0stage in
<7>musb_g_ep0_queue 917: queue to ep0 (OUT/RX), length=9
<7>musb_write_fifo 164: TX ep0 fifo fa0ab020 count 9 buf cf8aec00
<7>musb_g_giveback 144: ep0 done request cf8be6c0,  9/9
<7>musb_interrupt 1536: ** IRQ peripheral usb0008 tx0001 rx0000
<7>musb_g_ep0_irq 628: csr 0000, count 0, myaddr 43, ep0stage out/status
<7>musb_interrupt 1536: ** IRQ peripheral usb0000 tx0001 rx0000
<7>musb_g_ep0_irq 628: csr 0000, count 0, myaddr 43, ep0stage idle

まだ続くけど、ここまで。


.configで目立った変更は、こんなところか。

CONFIG_USB_MUSB_PERIPHERAL
CONFIG_USB_GADGET_MUSB_HDRC
CONFIG_USB_ETH
CONFIG_USB_ETH_RNDIS

Peripheralにしているので、OTG関係の設定が出てこなかった。
他にも関係あるのかもしれないが、これで続けてみよう。

SmartQ5のソースファイル

なにげなくSmartQ5掲示板を見ていたら、昔の投稿が目に付いた。
どういうことかというと、SmartQ5の掲示板はスパムしか目に付かず、本当に内容があるものはごくわずかだからだ。

2月の投稿で、Coviaの人が「今月中にはcode.googleにソースをアップできます」みたいなことが書かれていた。
ソースファイルが出たなんていうアナウンスはなかったような・・・と検索すると、あった。

http://code.google.com/p/covia-opensource-smartq5-android-froyo/

えー、もうちょっと大きくアナウンスしてくれよ~。
あるいは・・・偽物なのか??
わざわざ偽物を作るほどのものではないと思うが、そう思わせるのも作戦のうちとか。。。

twitterにはアナウンスされてた・・・。
ひどい。。。掲示板に書いたものは掲示板でアナウンスしてくれよ。。。

2011/05/28

USBのログをまた見直す

だめだ、わからん。
わからないときは、現場に戻るべし。
カーネルのログを見てみよう。


<7>musb_interrupt 1536: ** IRQ peripheral usb0001 tx0000 rx0000
<7>musb_stage2_irq 816: SUSPEND (b_idle) devctl 99 power e0
<7>musb_stage2_irq 820: state (1) active (0)
<7>musb_interrupt 1536: ** IRQ peripheral usb0004 tx0000 rx0000
<7>musb_stage0_irq 385: <== Power=f0, DevCtl=99, int_usb=0x4
<7>musb_stage0_irq 647: BUS RESET as b_idle
<7>musb_g_reset 1995: <== B-Device addr=0 driver 'android_usb'

ここは、まだアイドル状態。
USBをPCに挿した直後というところか。
まずここでRESETしている。


<7>musb_interrupt 1536: ** IRQ peripheral usb0008 tx0001 rx0000
<7>musb_g_ep0_irq 628: csr 0001, count 8, myaddr 0, ep0stage setup
<7>musb_read_fifo 202: RX ep0 fifo fa0ab020 count 8 buf c0473ecc
<7>musb_read_setup 562: SETUP req80.06 v0100 i0000 l64
<7>musb_g_ep0_irq 810: handled 0, csr 0001, ep0stage in
<7>musb_g_ep0_queue 916: queue to ep0 (OUT/RX), length=18
<7>musb_write_fifo 164: TX ep0 fifo fa0ab020 count 18 buf cf904c00
<7>musb_g_giveback 144: ep0 done request cf8fd680,  18/18

ここがSETUPステージ。
countが8ってのは、デバイスリクエストのみでデータサイズ0のことだろう。


<7>musb_interrupt 1536: ** IRQ peripheral usb0008 tx0001 rx0000
<7>musb_g_ep0_irq 628: csr 0000, count 0, myaddr 0, ep0stage out/status

OUTステージか、STATUSステージか。
Interface誌の特集では、データステージかステータスステージになる、とある。
OUTってのは、データステージのことか?
SETUPステージで、80.06という要求が来ている。
これは、GET_DESCRIPTOR要求で、deviceが返さなくてはならない。
返すときは、ログが出ないのか?

と思ったが、SETUPステージの最後でqueueして、FIFOに積めて、done、とまでいっている。
さすがに送っているだろう。
問題は何を送っているかだ。
細かく言えば、SETUPでディスクリプタ要求されても、まずはハンドシェイクパケットを送ることになっている。
ディスクリプタを返すのは、次にHostからINトークンパケットが来た後だ。
18byteって大きいから、ハンドシェークパケットではなさそうだ。


<7>musb_interrupt 1536: ** IRQ peripheral usb0000 tx0001 rx0000
<7>musb_g_ep0_irq 628: csr 0000, count 0, myaddr 0, ep0stage idle

アイドルになった。


<7>musb_interrupt 1536: ** IRQ peripheral usb000c tx0000 rx0000
<7>musb_stage0_irq 385: <== Power=f0, DevCtl=99, int_usb=0xc
<7>musb_stage0_irq 647: BUS RESET as b_peripheral
<7>musb_g_reset 1995: <== B-Device addr=0 driver 'android_usb'

リセットがかかった。


うーん、ハンドシェークパケットを送っていないのが問題なのか?
DMA転送がうまくいってないかも、とPIO設定にしてみたが、特に変化なし。
うーむ。。。。。。。

MUSBのSUSPENDとRESETを無効にしてみるが、そういう問題ではない

理由は不明だが、SETUPトークンの次にUSB HostからRESET/SUSPENDが来ることがあるようなので、MUSBのSUSPENDを無効にしてみよう。

<7>musb_interrupt 1530: ** IRQ peripheral usb000c tx0000 rx0000
<7>musb_stage0_irq 385: <== Power=f0, DevCtl=99, int_usb=0xc
<7>musb_stage0_irq 647: BUS RESET as b_peripheral
<7>musb_g_reset 1995: <== B-Device addr=0 driver 'android_usb'
<7>musb_g_disconnect 1939: devctl 99


・・・単にSUSPENDしないだけで、その次にRESETされてるのを忘れていた。
では、毒喰らわば、ということで、リセットも無効にしてみた。
しかし、単にリセットしないだけで、結局SETUPからリトライされている。
しまいには「peripheral reset irq lost!」なんて怒られてしまった。

Host側のdmesgは、こうなっていた。

[25684.100447] usb 1-4.4: new high speed USB device using ehci_hcd and address 105
[25684.210418] usb 1-4.4: no configurations
[25684.210428] usb 1-4.4: can't read configurations, error -22
[25684.300428] usb 1-4.4: new high speed USB device using ehci_hcd and address 106
[25684.410404] usb 1-4.4: no configurations
[25684.410414] usb 1-4.4: can't read configurations, error -22
[25684.500423] usb 1-4.4: new high speed USB device using ehci_hcd and address 107
[25684.530485] usb 1-4.4: no configurations
[25684.530495] usb 1-4.4: can't read configurations, error -22
[25684.620363] usb 1-4.4: new high speed USB device using ehci_hcd and address 108
[25684.650607] usb 1-4.4: no configurations
[25684.650617] usb 1-4.4: can't read configurations, error -22
[25684.660101] hub 1-4:1.0: unable to enumerate USB device on port 4

うん、昔から変わってない。
「unable to enumeration」だ。



「peripheral reset irq lost!」が気になったので、追ってみた。
これは、SETUPパケットを読んだ後、通信速度が未定だった場合に出ている。
ということは、あのRESETには通信速度を決める意味があるのか?

確かに、musb_g_reset()内でmusb->g.speedを決める処理があった。
決める箇所は、ここか、「reset irq lost!」のところだけだ。
通信速度g.speedは、状態を見極める意味で使われているところがままある。

もしや、と、通信速度が決定したらRESETさせない、とすると・・・同じだった。
うーん、どうもそういう問題ではないようだ。

USBのEnumeration (2)

USBのSUSPENDについて検索すると、Renesasのページが見つかった。
よくわからんが、Hi-SpeedモードではSUSPENDとRESETの区別はつかないらしい(どちらもD+, D-をLに落とすため)。
こっちのページには、USBを接続してからの流れが書いてあった。
ふむふむ。

ここで「Enumeration」という言葉が出てくる。
kernelのログにもよく出てくるのだ。「Enumerationできなかった」という形で。
どうやら、セットアップステージからはじまる一連の流れらしい。

ついでなので検索してみると、興味深いページが出てきた。
こちらによると、SETUPでGET_DESCRIPTORのあと、Hostからリセット要求が来ている、とある。
Renesasのページでは、SUSPENDとRESETの区別はつかないとある(状況次第だが)。
そう考えると、同じ状況のように見える。


この方は、RESETに対して特に何もしていないとのことであった。
MUSBでは、musb_g_suspend()を呼び出している。
<7>musb_g_suspend 1903: devctl 99
このdevctlは、MUSBのレジスタらしく、0x99だ。
 MUSB_DEVCTL_BDEVICE     0x80
 MUSB_DEVCTL_VBUS           0x18
 MUSB_DEVCTL_SESSION      0x01
この3つをORすると、0x99になる。
推測だが、「USB-B側で動作していて、VBUS供給されていて、通信中」というところか。
USB-B側になっている場合、ドライバにSUSPEND要求を出している。
それが、
<7>android_usb gadget: suspend composite
ということか。


なんとなく、話がつながったように思える。

SET_FEATUREがこないとHNPを有効にできない

USBのデバイスリクエストに、SET_FEATUREというものがある。
これがきて、パラメータで「HNPを有効にせよ」と言われないと、有効にできないようだ。
ログを見る限りは、SET_FEATUREが来てないなあ。

しかし、別にBeagleBoardはHostになりたいわけではない。
どっちかというと、SUSPENDの方がよろしくないのかな?

musb_debugを有効にしてみる

musb_core.cに、musb_debugという変数がある。
これを0以外にするとログが出るようだ。
やってみよう。
途中で気づいたのだが、デバッグレベルはいくつかある。
今回は3でやったけど、4が最大のようだ。


<7>musb_stage2_irq 812: SUSPEND (b_idle) devctl 99 power e0
<7>musb_stage0_irq 385: <== Power=f0, DevCtl=99, int_usb=0x4
<7>musb_stage0_irq 647: BUS RESET as b_idle
<7>musb_g_reset 1995: <== B-Device addr=0 driver 'android_usb'
<7>musb_read_setup 560: SETUP req80.06 v0100 i0000 l64
<7>musb_g_ep0_irq 808: handled 0, csr 0001, ep0stage in
<7>musb_g_ep0_queue 914: queue to ep0 (OUT/RX), length=18
<7>musb_stage2_irq 812: SUSPEND (b_peripheral) devctl 99 power f0
<7>musb_g_suspend 1903: devctl 99
<7>android_usb gadget: suspend composite
<7>musb_stage0_irq 385: <== Power=f0, DevCtl=99, int_usb=0xc
<7>musb_stage0_irq 647: BUS RESET as b_peripheral
<7>musb_g_reset 1995: <== B-Device addr=0 driver 'android_usb'
<7>musb_g_disconnect 1939: devctl 99
<7>musb_read_setup 560: SETUP req80.06 v0100 i0000 l64
<7>musb_g_ep0_irq 808: handled 0, csr 0001, ep0stage in
<7>musb_g_ep0_queue 914: queue to ep0 (OUT/RX), length=18
<7>musb_stage2_irq 812: SUSPEND (b_peripheral) devctl 99 power f0
<7>musb_g_suspend 1903: devctl 99
<7>android_usb gadget: suspend composite
<7>musb_stage0_irq 385: <== Power=f0, DevCtl=99, int_usb=0xc
<7>musb_stage0_irq 647: BUS RESET as b_peripheral
(以下、略)

今まで「susupend composite」だけだったのが、ばらばらっと出るようになった。
ep0は、エンドポイント0だろう。
b_peripheralとあるし、irqってのもあるから、セットアップステージをやろうとしているところか。


<7>musb_read_setup 560: SETUP req80.06 v0100 i0000 l64
ここはSETUPパケットを読むところだ。
デバイスリクエストはこうなっている。
 ・bmRequestType : 0x80(Dir:device=>host, Type:standard, RX:device)
 ・bRequest : 0x06(GET_DESCRIPTOR)
 ・wValue : 0x0100(DescType:DEVICE, DescIndex:0x00)
 ・wIndex : 0x0000(Language:none)
 ・wLength : 64


ディスクリプタタイプ"DEVICE"は「標準デバイスディスクリプタ」と呼ばれるもので、これにベンダIDやプロダクトIDなどを入れてHostに返すそうだ。
って、これはPCが返してるってことかい?
でも、方向はdevice=>hostとなっている。
データはエンドポイント0のFIFOから読み出しているようなので、少なくともBeagleBoardから出そうとしているデータではない。

ああ、「デバイスリクエスト」だから、HostがDeviceに対して要求しているのだな。

方向がdevice=>hostなのは、要求したデータをdeviceからhostへ返しなさい、ということか。
RXがdeviceなのも、「この要求はdeviceが受け取りなさい」ということか。

ということはこのログは、セットアップステージのうちのデータパケットを表しているということか。
最初のSETUPトークンはログに出すほどでもないということでいいのかな。


<7>musb_g_ep0_irq 808: handled 0, csr 0001, ep0stage in
これはエンドポイント0割り込みのログ。
色付けしたところがパラメータだ。
CSRはなんだかわからないけど、CSR0というレジスタがあるらしい。
"in"はエンドポイント0の状態らしい。受信ということか。
USBのシーケンスとしては、セットアップステージの次はデータステージになっていて、その始まりがINパケットらしい。
その"IN"かもしれん。


<7>musb_g_ep0_queue 914: queue to ep0 (OUT/RX), length=18
キューってことは、データをキューに詰めているところか?
こっちは"OUT/RX"か"IN/TX"のどちらかしか表示されない。
が・・・なんだろう。OUTとIN。
これは、host=>deviceがOUT、device=>hostがINだそうだ。
Host中心なのだな。


<7>musb_stage2_irq 812: SUSPEND (b_peripheral) devctl 99 power f0
ここはUSBの汎用割り込みらしい。
SUSPEND割り込みが入った、と思われているのか。
そして状態がOTG_STATE_B_PERIPHERALなので、分岐して・・・

あれ、HNPのログが出てない。
ソースからすると、ここでHNPに処理が進みそうなのだが、そのログが出てない。
ログを埋め込んだところ、musb->xceiv->gadget->b_hnp_enableが0だった。
つまり、HNPが使えないってことか。
そこら辺が問題なのか。。。実は関係ないのか。。。

OTG関係のkernelログを見直す

ログを疎かにしたらいかん。
自分で埋め込んでいないから何が出るか分からないけど、何かしら情報があるかもしれない。


まずは、MUSBの初期化部分。
MUSBはMentor Graphics社のUSB IPを操作するためのライブラリだと思っている。
OTGモードであるとわかっている。

musb_hdrc: version 6.0, musb-dma, otg (peripheral+host), debug=0
musb_hdrc: USB OTG mode controller at fa0ab000 using DMA, IRQ 92


しばらくするとhost driverのログが出てくる。
「usb2」となっているのは、usb1としてEHCIポートが使われているからだ。
下の方で、今回追加したADK関係のf_accessoryが登録されている。

musb_hdrc musb_hdrc: MUSB HDRC host driver
musb_hdrc musb_hdrc: new USB bus registered, assigned bus number 2
usb usb2: New USB device found, idVendor=1d6b, idProduct=0002
usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb2: Product: Љ
usb usb2: Manufacturer: Љ
usb usb2: SerialNumber: Љ
usb usb2: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 1 port detected
f_accessory init
android_register_function accessory

よく考えると「host driver」となっているが、これはUSB Hostの意味か?
そして、USBハブを検出しているようだ。
いくら「Dual Role Device」とはいえ、HostとPeripheralを同時に動かすことはできまい。


dmesgログの方がいろいろ出ているので、同じところを振り返ってみよう。

まずはMUSBの初期化。

<6>musb_hdrc: version 6.0, musb-dma, otg (peripheral+host), debug=0
<7>musb_hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine (X), bulk split (X), HB-ISO Rx, HB-ISO Tx, SoftConn)
<7>musb_hdrc: MHDRC RTL version 1.400
<7>musb_hdrc: setup fifo_mode 4
<7>musb_hdrc: 28/31 max ep, 16384/16384 memory
<6>musb_hdrc: USB OTG mode controller at fa0ab000 using DMA, IRQ 92

続いて、登録しているところ。
android_bindは関係ないかも。

<6>android init
<6>android_probe pdata: c047f464
<6>android_bind
<7>android_usb gadget: adding config #1 'android'/c04a3740
<7>android_bind_config
<7>android_usb gadget: cfg 1/c04a3740 speeds:
<6>android_usb gadget: android_usb ready
<6>musb_hdrc musb_hdrc: MUSB HDRC host driver
<6>musb_hdrc musb_hdrc: new USB bus registered, assigned bus number 2
<6>usb usb2: New USB device found, idVendor=1d6b, idProduct=0002
<6>usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
<6>usb usb2: Product: Љ
<6>usb usb2: Manufacturer: Љ
<6>usb usb2: SerialNumber: Љ
<6>usb usb2: configuration #1 chosen from 1 choice
<6>hub 2-0:1.0: USB hub found
<6>hub 2-0:1.0: 1 port detected
<6>f_accessory init
<6>android_register_function accessory

あまり変わりはしないな。
やはり気になるのは、Hostとしてハブを検出しているところ。
そういえば、SmartQ5をadbとして使うときには設定画面で切り替えたりしたな。
内部では、USBを切り替えるようなコマンドを実行させていたと思う。
そういったトリガを内部から実行しないといかんのだろうか。

BeagleBoardでEHCIポートは使えるんだ!

長いこと、使えないと思い込んでいたものが使えると、うれしいものである。
ここでの「使えない」は、「こいつ使えないやつだな」ではなく、文字通り「使用できない」の意味だ。

BeagleBoardのUSB Aレセプタブル(でいいのかな?)は、購入当時はうまく動かせなかったのだ。
なので、ずっとOTGポートを使っていた。
しかし今は、OTGポートでPeripheralになる確認をしているので、Hostとして使えるポートがほしかったのだ。
何気なく挿してみると、あっさり動いた。
ちゃんと、Displaylinkで画面も出ているし、USBカメラにも電源が入ってる。
いやあ、やってみるものですな。

2011/05/27

Google Walletってのができるらしい

http://www.google.com/wallet/

Google Walletってのができるらしい。
Citibankだけではなく、他の銀行カードからでも使えるようになるとか。

まあ、中身はいいとして(いいのか?)、どうやるんだろう。
FAQには、ISO14443やISO18092がいるとあるし、Secure Elementに置くともある。
PIN、という文字があるので、USIMに置くのか。
SIMとの通信も、なんとかってプロトコルがあったと思うが、失念してしまった。。

たしか、GoogleはSecure Elementは使いたくない、といってたような。
あと、P2Pでやりたいとか。
でもそのうちのSEは使うっていってるしな。。。
P2Pもどうなのかわからん。
プラスチックカードっていってるから、P2Pではないのかも。
P2Pだと、自分で無線出せないと意味がないような気がする。

14443とか18092だけでは、無線プロトコルとコマンドくらいしか規定していないのではないか。
いや、14443は知らんので推測だが。
USIMへのアクセスは、何かしら共通するプロトコルがあるとなると、しくみだけであればopenだと思う。
現在のFeliCaチップではUSIMにアクセスできないと思うので、まだカード代わりにはなれないかも。
USIM<=>FeliCa SEコンバータが入ればいいんだろうけど、そんなのなかったと思う。

あー、思う思うばかりで、なにも自分がわかってないことだけがわかる、と。

uImageを読む前まではPeripheralとして動いている

何気なくBeagleBoardに電源を入れた。
SDカードの挿し方が悪かったのか、uImageを読み込まずに立ち上がってしまった。
ふっと思いつき、その状態のままOTGポートからパソコンのUSB-Aに挿してみた。

otg_uboot.png

おや、認識している!
この「a4a6」はなんだろう?


u-bootを解凍してみると、drivers\serial\usbtty.hのCONFIG_USBD_PRODUCTID_GSERIALだった。
これしかないから、これなんだろう。
なんとなく、default:でこの値になったような感じ。

プロダクトIDは0xa4a6でいいとして、ベンダIDの0x0451はどこだ?
http://www.linux-usb.org/usb.ids
によると、TIだ。
ああ、そうね。
ソースファイルを検索したけど、それっぽい値が見当たらない。
デバイスが持つ値を使っているのかな?


Linux(ubuntu10.10)に挿したときのdmesgログも残しておこう。
lsusbでは出てこなかった。
/proc/bus/usbはディレクトリ自体がなかったのは、kernel設定だろう。

[  182.150395] usb 1-4.4: new high speed USB device using ehci_hcd and address 8
[  197.230446] usb 1-4.4: device descriptor read/64, error -110
[  212.420408] usb 1-4.4: device descriptor read/64, error -110
[  212.610383] usb 1-4.4: new high speed USB device using ehci_hcd and address 9
[  227.690427] usb 1-4.4: device descriptor read/64, error -110
[  242.880482] usb 1-4.4: device descriptor read/64, error -110
[  243.070443] usb 1-4.4: new high speed USB device using ehci_hcd and address 10
[  253.490094] usb 1-4.4: device not accepting address 10, error -110
[  253.570396] usb 1-4.4: new high speed USB device using ehci_hcd and address 11
[  263.990105] usb 1-4.4: device not accepting address 11, error -110
[  263.990385] hub 1-4:1.0: unable to enumerate USB device on port 4
[  555.110472] usb 1-4.4: new high speed USB device using ehci_hcd and address 12

うーん、ベンダIDすら出てこないのか。
なんでだろう・・・・
あ、使ってるu-bootが違ってた。
上記のログが出たのは、


U-Boot 2009.01-dirty (Feb 19 2009 - 12:22:31)

で、ちゃんと動いたのは

U-Boot 2010.03 (Feb 20 2011 - 20:15:58)

だった(括弧内の日付が新しいのは、自分でビルドしたからだろう)。

では、気を取り直して。

[ 2504.570397] usb 1-4.4: new full speed USB device using ehci_hcd and address 28

lsusbにも出てくる。

Bus 001 Device 028: ID 0451:a4a6 Texas Instruments, Inc.

ここまでで分かったのは、以下だ。

  • U-Boot 2009.01ではPeripheralで動かないバージョンがあるようだ
  • U-Boot 2010.03ではPeripheralで動くようだ
  • ということは、Linuxのkernelが動いた後でPeripheralになれなくなったことになる
U-Bootとkernelの間には何もないので、後はkernelのことだけ考えればよいことになる。
範囲は狭くなった。

2011/05/26

RC-S620/SでMIFAREは読める

まあ、タイトル通りだ。
もちろん、PaSoRiでもできる・・・はず。
そっちは確認してない。
年始に調べたときの資料なので、まあ間違ってなかろう。

Polling

typea_polling.png

R/W

typea_rw.png

u-bootも何とかした方がよいのか?

Linux側のOTGがうまく動いていない、という推測で進めている。
MUSBを見てみよう、というのもそういうことなのだが、その前も少し気にした方がいいのだろうか。
というのも、u-bootのMUSB対応、みたいなものがあったからだ。

BeagleBoardは、x-loader⇒u-boot⇒Linux、というような流れで起動している(と思う)。
なので、Linuxがうまく動けばいいや、と思っていたが、ブートローダでしか行っていない初期化、みたいなものがあるのだろうか。。。
まあ、やってみればわかることだ。

2011/05/25

Dual Role Device

HostとPeripheralの両方になれる。
それがDual Role。
Dual Roleできるデバイスだから、Dual Role Device。

DRD、と略すらしいが。。。あまり聞かないな。


Linuxのkernel設定でも、DRDのことが出てくる。
項目としては、Dual Role Controller、DRCだ。
ハイスピードに対応しているので、HDRC。

BeagleBoardに搭載されているOMAP3530は、Mentor社のライブラリ、MUSBを使えるようだ。
Mentor社はUSBの機能部品提供をしていて、それを使うLinux用のライブラリを無償提供しているようだ。
ありがたや。

さて、やはりMUSBの動きを知らないと、なぜ今Peripheralとして動作しないのかがわからない。
私はそう思う。

そもそもOTGとは (4..end) - SRPの必要性

HNPは「自分がHostになる」というような交渉をするプロトコルだ。
これは、ケーブルのA/BでHost/Peripheralが決まるという仕様があるので、必要性がわかる。

では、SRPはなぜ必要なのだろう?
その説明が、Maximのページにあった。

おおざっぱに言えば、眠ってしまったHostを起こすためのものだ。
携帯電話が、USBでつながっているとする。
Host側は常にVBUS(電源)をPeripheralに供給しないといけないけど、通信してないのでHostがVBUSを落として眠ってしまったとしよう。
そのとき、Peripheral側の端末が起きて、通信したくなったとする。
ここでSRPが役立つ。
「SRPパルス」なるブロックをD+(信号線)に載せると、Host側はVBUSを生かして起き上がるらしい。


4回に渡って調べたことで、OTGの概要はだいたいわかったと思う。
あとは実践だ!

そもそもOTGとは (3) - 実際のチップ仕様を見てみる

Maximのページに、OTGの説明があった。
概要がわかっても、実際にどうなのかがわからないと、ぴんと来ないものがある。
そういうときは、チップをどうやれば動くのかを見ることができるなら、そうする手もある。
まあ、国内のページでもよいのだろうけど、単に検索で見つからなかっただけだ。

読みたいが、さっき見つけたばかりで、もう出社する時間だ。
さらばだっ。


"fifth pin(ID)"って書いてあるけど、IDって4番ピンよね?
あるいは、USBのminiじゃないケーブルは4ピンなので、5ピン目として追加した、という意味かな。

OTGであることをすこしわかってくれた

OTGのことだけ調べていても飽きるので、少し動かしてみた。
sysfsのところを見てみると、なにやら見えるらしい。
miniBを接続して、PCに挿してコンソールを操作。

# cat /sys/devices/platform/musb_hdrc/mode
b_peripheral

おお、自分が周辺だってわかってるんだ!
では、USBを外してやってみよう。

# cat /sys/devices/platform/musb_hdrc/mode
b_idle

おお。
ちょっとうれしい。

自分に周辺機器をつなぐとHostになるのかな?

# cat /sys/devices/platform/musb_hdrc/mode
b_idle

それはなさそうだ。
やはり、miniBケーブルだからだろう。
なぜminiBだとそうなるかというと、4pinの扱いがオープンだからだ。
Hostになるためには、GNDにおちてないといかん。
それがルール。

しかし、だ。
きっとソフト的にやる方法もあるはずだ。
うちのSmartQ5ってUSBシリアルケーブルが使えるけど、ソフト設定するとminiBケーブルでadbできるのだ。
そこまでやらないかんですな。

2011/05/24

そもそもOTGとは (2) - AとB

OTGだからといって、USBコネクタのAとBが無関係というわけではない。
AはHost側に挿すし、 BはTarget側に挿す。
単に、TargetがHostになる、というようなプロトコル(HNP)が用意されているだけだ。

eLinux.orgによる説明も、そのことが書いてあった。
miniAケーブルのように、Pin4(ID)がPin5(GND)とショートしているようなものを使うと、Hostとして動きますよ、というような説明だ。

私は、miniBケーブルしか持っていない。
だから、BeagleBoardのパターンを直接半田付けして、強制的にHost用にしてしまっていたのだ。
それを外したので、Hostとして動作しなくなったということになる。

あとは・・・LinuxでHNPがどうやったら動作するか、ということを調べるといいのかな?

2011/05/23

そもそもOTGとは (1)

毎回調べて、毎回忘れる。それが人間という生き物だ。
しかし、前回調べたという記憶はあるので、資料として残しておくと便利だろう。
OTGのことも、然り。



もともと、USBはHost--Target間の通信で、必ずどちらかがHostになるという非対称通信だ。
昔はパソコン同士をUSBで接続してファイルをやりとりするケーブルがあったけど、それは間に仲介する装置が入っていたのだと思う。
これが前提。

しかし、どっちがHostになるか決めにくいものがある。
デジタルカメラとプリンタを接続した場合などだ。
どっちもパソコンとつなぐのだったら、パソコンがHostでよいのだが、さてどうしたものか。

そこで出てきたのが、OTG。
On-The-Goの略で、これは規格名だ。
もう、ここを読んでいただければわかるはず。。。

で済ませてきたので、記憶に残っていないのだ。
自分で整理せねば。


OTG企画の目標は、お互いがHostにもTargetにもなれること。
これを「デュアルロールデバイス」という。

補足説明に、デュアルロールデバイスの説明がある。
USBは接続すると、セットアップステージ→データステージ→ステータスステージの順で通信を行うが、これらの開始はすべてHostからとなる。
OTGのミニABコネクタの場合、ケーブルのミニAもミニBも挿すことができる。
ルールとしてはミニA側がHost、ミニB側がTargetだと考えられる。

しかし、自分から通信を開始したいのにミニBが挿されてしまった、ということもありうる。
そんなときOTGは、Hostになりたい、という要求を出せるらしい。
それこそがOTG規格の本質とのこと。

Targetが通信を開始したい、という宣言をSRP(Session Request Protocol)、TargetがHostになりたい、という交渉をHNP(Host Negotiation Protocol)というそうだ。



さて、ここまでで規格の概要はわかった。

しかし、もう少し詳細が知りたい。
ケーブルのAとかBとかも、ちゃんと知っておきたい。
というのも、BeagleBoardのOTG説明に気になるところがあるからだ。

今週は、OTG調査で終わってしまうな。

BeagleBoardでOTGできそうなカーネルを探しています

大佐じゃないですぞ。
探しているのは、BeagleBoard(xMではない)で動作して、OTGも使えるカーネル。
もしかするとdefconfigの設定が悪いだけかもしれないけど、探しておいて損はなかろう。


まず、Android本家。
最新は、android-omap-2.6.39のようだ。
git://android.git.kernel.org/kernel/omap.git

rowboatさん。
2.6.37。
http://gitorious.org/rowboat/kernel

LinaroはxMと書いてあるので、違うのだろう。これはOESFさんのLinaro(android用)。
2.6.35.9。
https://github.com/OESF/Linaro-Android_LinaroSprint2011Q1

OESFさんのEM3.0にあるカーネル。
2.6.32.9。
https://github.com/OESF/Embedded-Master-ARM/tree/master/kernel/beagleboard

solaさんのAndroid2.3にあるカーネル。2.3.4相当だったか。
2.6.32.9。
https://github.com/sola-dolphin1/OHA-Android-2.3_r1.0/tree/master/kernel/beagleboard

2011/05/22

linaroのxconfigでエラーになった

Beagleboard用のカーネルをあれこれ探しているが、どれもうまくいかない。 というよりも、Beagleboardの新しいカーネルが見つからない。 2.6.35くらいがいいんだけど。。。 そんなわけで初心に返り、linaroのカーネルを使ってみることにした。
困ったときのOESFさん、だ。

ビルドしようとmake xconfigすると、こっちはこっちでエラーになった。

$ make xconfig
  HOSTCXX scripts/kconfig/qconf.o
In file included from scripts/kconfig/qconf.cc:31:0:
scripts/kconfig/qconf.moc:11:2: error: #error "The header file 'qconf.h' doesn't include ."
scripts/kconfig/qconf.moc:18:1: error: ‘QT_BEGIN_MOC_NAMESPACE’ does not name a type
(以下略)

さっきと違う。
設定を元にもどしたけど、だめだ。
Qt3とQt4の違いかと思ったんだけどなぁ。

と思ったら、1つ忘れていた。
Qt3に戻して、



$ make distclean
$ make xconfig

はい、うまくいきました。
2.6.35は、またQt3なのだな。
2.6.37くらいからQt4になったようだ。

xconfigでエラーが出る

qt4を選べばよいらしい。

$ sudo update-alternatives --config moc

  Selection    Path              Priority   Status
------------------------------------------------------------
* 0            /usr/bin/moc-qt3   45        auto mode
  1            /usr/bin/moc-qt3   45        manual mode
  2            /usr/bin/moc-qt4   40        manual mode

Press enter to keep the current choice[*], or type selection number: 2
update-alternatives: using /usr/bin/moc-qt4 to provide /usr/bin/moc (moc) in manual mode.

$ make distclean
$ make xconfig

omapzoomはOMAPに注目する、ということではなかった

OmapZoomというものがある。
wikipediaによると、TIが出したモバイル開発環境らしい。

しかし、私はそれを知らなかった。

「omap kernel」で検索すると、omapzoomというサイトが出てきたのだ。
これがOmapZoomの紹介をしていたなら気づいただろうが、表示されたのはandroid.kernel.gitにあるようなgitのページだった。
「これはきっと、OMAPに着目したサイトに違いない!」と思った私を誰が責められようか。

kernelを落としてきて、BeagleBoard用にビルドしようとしてもあちこちうまくいかず、ビルドを通してもコンソールが出ず、なんじゃこりゃ、と思って検索したら、ようやくわかったという次第。

つまりここは、omapzoom向けのkernelが置いてあるんですな。
気づくのに2時間かかったよ。。。

[git]リモートからgit cloneしてbranchを変更

メモ書き。

git cloneをそのままやっただけだと、masterになる。
git branchとしても出てこないけど、どうやるんだ?ということ。

$ git branch -a
* master
  remotes/origin/HEAD -> origin/master
  remotes/origin/android-omap-2.6.29
  remotes/origin/android-omap-2.6.29-eclair
  remotes/origin/android-omap-2.6.32

$ git checkout -b android-omap-2.6.29 origin/android-omap-2.6.29



だいたい、こんなイメージで良さそうだ。
clone時に-bすればよさそうな気もするが、まあいいや。

2011/05/21

suspendログを出しているのはcomposite.cということだけわかった

なんだかわからないログ。

android_usb gadget: suspend composite


これはcomposite_suspend()で出していた(本当は「suspend」だけだったので、"composite"を付け加えた)。
いやあ、わからんかったですわ。

というのも、これはkernel設定の「USB_GADGET_DEBUG」を有効にしたときに出始めていたので、grepも「USB_GADGET_DEBUG」で調べていたからだ。
しかし出てこない。。。
いっぱい出てくるならまだしも、ほとんど出てこないのだ。
なので、なにがどうなって出力したのかがつかめず、また「suspend」などでは気づかなかったというところ。


まさかcomposite.cとは。
Makefileでひっかからなかったので細かく見てみると、android.cの中でincludeしてた。
ほー、そういう系統のファイルなのね。。。

それ以上のことは、まったくわかってませんわ。

BeagleBoardをUSBターゲットにしたいが、うまくいかん

うまくいかんシリーズです。

LinuxカーネルのUSB Gadgetがターゲットにするために必要ということが分かった。
ならば、と設定を見てみたが、USB Gadgetは有効になっている。
HostにもOTGにもなれるような設定も有効だ。

なのに、PCに挿しても反応がよくない。

[12907.100476] usb 1-4.4: new high speed USB device using ehci_hcd and address 34
[12907.210315] usb 1-4.4: no configurations
[12907.210326] usb 1-4.4: can't read configurations, error -22
[12907.300461] usb 1-4.4: new high speed USB device using ehci_hcd and address 35
[12907.410301] usb 1-4.4: no configurations
[12907.410310] usb 1-4.4: can't read configurations, error -22
[12907.500448] usb 1-4.4: new high speed USB device using ehci_hcd and address 36
[12907.530399] usb 1-4.4: no configurations
[12907.530408] usb 1-4.4: can't read configurations, error -22
[12907.620442] usb 1-4.4: new high speed USB device using ehci_hcd and address 37
[12907.650392] usb 1-4.4: no configurations
[12907.650401] usb 1-4.4: can't read configurations, error -22
[12907.660167] hub 1-4:1.0: unable to enumerate USB device on port 4


こんな感じだ。
とにかく、configurationというものを返してくれないようだ。
USBのデバイスリクエストに「GET_CONFIGURATION」というのがあるから、その要求をPCから投げたのに返さないのだろう。

ってことは、USB Gadgetがうまく動いていなさそうだ。

では、BeagleBoard側のログを見てみよう。

android_usb gadget: android_usb ready
f_accessory init
android_register_function accessory

こんなログがあるので、ドライバは読み込まれているようだ。

<7>android_usb gadget: adding config #1 'android'/c04ccf60
なんだかわからないが、追加されたようだ。
挿すと、こんなログ。

<7>twl4030_usb twl4030_usb: HW_CONDITIONS 0xd0/208; link 2
<7>android_usb gadget: suspend
<7>android_usb gadget: suspend
<7>android_usb gadget: suspend
<7>android_usb gadget: suspend


抜くと、こんなログ。

<7>twl4030_usb twl4030_usb: HW_CONDITIONS 0x50/80; link 1
以上。


気になるのは、これか。
<7>android_usb gadget: suspend
suspendしているから、反応しないのかな?

f_accessoryのfはfunctionのf

gadget/android.cかと思っていたが、ネットで検索するとf_accessory.cというものがあるそうだ。
プロダクトIDの0x2d00を検索してf_accessory.hが出たのまでは確認したのだが、そのソースがあるとは・・。
ぬかったわ。
つまり、f_accessory.cを移植すればいいってことかしらね。
「Gadget Function Driver for Android USB accessories」と書いてあるから、fはfunctionのfらしい。

ソースファイルとしては、今年の3月に追加されたようだ。
ってことは、それ以前のカーネルに対してはパッチを当てるようになるのか。
幸い、修正が必要なのはKconfig、Makefile、android.cの3つくらいのようだ。
BeagleBoardのカーネルを新しくできるといいんだけど、やり方がよくわからない。。
それならパッチの方がやりやすい。
中身はまったく見ていないが、きっとうまくやってくれるはず!

USB GadgetはUSB Targetだったんだ

USB GadgetはUSB Targetだったんだ!!
kernelの設定で何気なく使っていたけど、そういう位置づけだったのね・・・。
うれしかったので、わざわざ記事にしてしまった。

おそらく、drivers/usb/gadget/android.cがそれに相当するのかな。
でも、

#define VENDOR_ID 0x18D1
#define PRODUCT_ID 0x0001
だしなぁ・・・。
0x2d00にORするという展開でもなさそうだ。
うーむ。
参考にしているソースが対応していないのか、見るファイルがそもそも違うのか・・・。

Android Accessory Protocol,略してAAP

Android 2.3.4では、アクセサリモードをサポートしている。
ホストモードはない。
ないなら、誰かがホストになってくれなくてはならない。
ホストになるためには、ホストとして何をすべきかを知らねばならない。
するべきことといえば、通信だろう。
そんなわけで、プロトコルのところを読んでみた。

ざっと訳してみたが、ポイントとしては
  • ベンダIDはGoogleの0x18d1
  • プロバイダIDは0x2d00か0x2d01(adbあり)
  • そうじゃないデバイスだったら、アクセサリモードになるように要求する
  • アクセサリモードになると、ベンダIDとプロバイダIDが上記になる
そんなところだ。
さて、Hostを作る前にBeagleBoardなどがTargetにならなくてはならない。
自分にささったデバイスに対するドライバは何となくイメージが付くのだが、自分がTargetになるんだったらどうやるんだろう?
そこら辺は、まだわからん。

Arduinoも3.1も持っていない場合はどうしたものか

Open Accessory APIが追加されてよかったものの、うちにはAndroid2.3.4の環境くらいしか作れない。
2.3.4は、Hostにはなれない。
うーん・・・

まずは、android developersのブログを読んでみよう。

Open Accessory APIは、ライセンスなしでUSBアクセサリをAndroid3.1や2.3.4につなぐことができる。
新規の「アクセサリモード」はUSBホストになるAndroid端末はなくてもよい。
USBプロトコルは非対称(ホストと非ホストの通信になるから)。
パソコンだと、PCがUSBホストになり、それ以外のマウスやプリンタなどの非ホストデバイスがつながる形だ。

USBホストは2つの大きな役割がある。
まず、バスマスタになってデータの流れを制御する役割。
それと、電源を供給する役割。

Androidが従来のやり方でUSBアクセサリに対応するのには、問題があった。
それは、いくつかのデバイスがホストモードをサポートしているというものだ。
解決するために、こうした。
アクセサリモードでは、Android側がUSBデバイスとして振る舞い、アクセサリがUSBホストとして動く。
つまり、アクセサリ側がバスマスタになり、電源を供給するということだ。

まあ、そういうことらしい。
バスマスタ機能と電源供給は、USBホストになるものであれば持っているだろう(USBはよく知らんが)。
あとは、USBアクセサリとして動くAndroidとどうやって通信したらいいんだ?ということだ。
そうか・・・だから次の「Establishing the Connection」があるのか。。。

接続の確立
Open Accessoryの構築は、USBホストとして動いて電源供給できるなら簡単。
VIDは0x18d1、PIDは0x2d01か0x2d00。

簡単らしいから、省略だ。
VIDはAndroidのものなのだな。

;Google NexusOne
%SingleAdbInterface% = USB_Install, USB\VID_18D1&PID_0D02


こんなものがあるので、気になってはいたのだ。
PIDは・・・気にすまい。

とにかく、2.3.4はホストになれないのであれば、一番身近なホストは誰だ?
PCだろう。
なので、一番よく使っているOpen Accessoryはadbなんじゃなかろうか?
ほら、API12のサンプルにもAdbTesってのがあるではないか。
昔から温めてきたものを整備して出した、というところなのかしら。
まあ、動かしてないので推測なんだけどね。

2011/05/20

USB Accessoryを少し見たかったが、惑わされる

Android 2.3.4では、USB Accessoryモードなるものが使えるらしい。
私がちょっと読んだ感じでは「自分がUSBアクセサリになって、USBホストになるマシンに接続できる」だと思っている。
だって、USBホストにはなれない、と書いてあるのだから、そうだよな?
Open Accessory Libraryの説明(の和訳)を見ると、ホストでもアクセサリでもどっちでもいけそうな感じで読めるが、これはAndroid 3.1向けに書かれているからだろう。
Android 2.3.4では、Hostはサポートしてない、と書いている。
前回、Android2.3.4用のSDKはないかもね、と書いたが、プラットフォームはAndroid 2.3.4が必要だ。
きっとそこには、USBライブラリなんかが載っているのだろう。
私がよくわからんかったのは、これ。
Peripherals that attach to Android-powered devices as accessories connect as USB hosts.
これは「as~as」構文のように見えるが、実は違う(間違わないか…)!
「Android搭載機器にアクセサリとして接続された周辺機器は、USBホストとして接続する」?
変だ・・・。
その前の文章を見ておこう。
Open Accessory is a new capability for integrating connected peripherals with applications running on the platform.
Open Accessoryは接続された周辺機器をアプリで使用するための新機能だ」くらいでいいのかな。
USBは、ホストとクライアント(だっけ?)の立場が明確に分かれているはずだ。
まあ、OTGってのもあるが、ここではよかろう。
USBホスト以外は全部USBクライアントだ。
最初の文章の骨組みは、こうだ。
Peripherals connect as USB hosts.
だけど、なんか変だ。
周辺機器の方がホストになるのか?
これは、Android 2.3.4はUSBアクセサリにしかならないから、自分を接続する人はUSBホストじゃないといかんよ、ということを説明しているのだろうか。
それならば、理解できる。
でも、そのあとで「Android 3.1ではホストもサポートするけど…」と書いてあるので、その意図はないと思っているのだ。
なんか、この一文が唐突すぎて、よくわからんのよね。
惑わされてしまった。

2011/05/18

CONFIG_USB_ANDROID_ACCESSORY

早く帰ってきた日くらい、ソースを見ておこう。

/dev/usb_accessoryが入り口になる、というところまでわかったので、kernelを見る。
さて、Androidのgitにはいくつもkernelがある。
どれがよいのだ?

気力がない私は、msm.gitにした。
やっぱり携帯電話と言えばQualcommなのかねぇ。

キーワードは「CONFIG_USB_ANDROID_ACCESSORY」。
何でかというと、最近のmsm.gitコミットログにあった文字列だから。
根拠が薄いなぁ。。。。

cgrepしてでてきたのは、ファイル2つ。

./drivers/usb/gadget/android.c:407:#ifdef CONFIG_USB_ANDROID_ACCESSORY
./arch/arm/mach-msm/board-mahimahi.c:146:#ifdef CONFIG_USB_ANDROID_ACCESSORY
./arch/arm/mach-msm/board-mahimahi.c:163:#ifdef CONFIG_USB_ANDROID_ACCESSORY
./arch/arm/mach-msm/board-mahimahi.c:197:#ifdef CONFIG_USB_ANDROID_ACCESSORY

まひまひ・・・。
なんだこれは・・・。

2011/05/16

USB Accessoryは/dev/usb_accessoryらしい

USB Hostはどうやって実現してるんだろう?とソースを見たくなった。
libusbなのだろうか? それとも何か汎用的なライブラリがあるのか?

とりあえず、UsbService.cppがあった。
こっからたどろうかと思ったのだが。。。。

そういえば、USB Hostは3.1からで、まだリポジトリにはないんだな、ということに気づいた。
/dev/usb_accessoryって文字列を見たからだ。
2.3.4はUSB Accessoryのみだったな。

open時に/dev/usb_accessoryを開くんだな、ということはわかるが、そこまでだ。
ioctl()で属性なんかを取得するところまでは、わかる。
あとはUsbService.javaとかか。
もういいや。。。

NFCは、packages/apps/Nfcみたいなところにあったけど、USBはframeworks/base/servicesみたいなところにある。
この扱いの違いは何だろう?
hardwareってものあるけど、NFCはexternal/libnfc-nxpで制御してるし。
wifiもexternal/wpa_supplicantでやってたような。

仕事でAndroidやってるわけではないけど、気にはなるなぁ。


まあいいや。
とにかく、kernelがusb_accessoryのドライバを持ってるだろうから、それを見ればいいだろう。
USB Accessoryだと自分が周辺機器になるので、なんか変な感じだ。

2011/05/12

Android3.1になると、USBホストになることができるのか

最近、PaSoRiをつなげたばかりだ。

しかし、Android3.1ではUSBホストになれるという。
APIもandroid.hardware.usbってのがあるし。
ベンダIDとかプロダクトIDなんて単語も見えるから…見えるから…?
どうやって、どうするんだろう?
まあ、こういうのはドキュメントを読まんとわからんが、それよりもAndroid3.1はソースが降りてきてないから、BeagleBoardなんかで遊べないな。

今のところ、Android2.3.4くらいで年末までしのぐしかなさそうだ。
といっても、2.3.4のSDKもまだ降りてきてないようですな。。。
ライブラリで何とかできるらしいけど、どうやるんだろう?

ああ、MTPなんかも載ってるから、メディアプレーヤー系の接続も容易になるのか。
いろいろ進んでて、おじさんついて行きにくいなぁ。。。

2011/05/11

Android2.3.4ではUSBアクセサリモードが使えるようになるらしい

Android2.3.4ではUSBアクセサリモードなるものが使えるようになるらしい。
というわけで、少し訳してみた

AndroidはさまざまなUSB周辺機器とAndroid USBアクセサリ(Android accessoryプロトコルを実装したハードウェア)をサポートする(USBアクセサリモードとUSBホストモード)。
USBアクセサリモードでは、外部USB機器がUSBホストとなる。ロボット制御、ドッキングステーション、診断や楽器、キオスク、カードリーダ、などなど。これはAndroidが搭載された、USBホストになれない機器である。Android USBアクセサリは、Android搭載機器で、Androidアクセサリ通信プロトコルが実装されていなくてはならない。
USBホストモードでは、Android搭載機器がUSBホストとなる。デジタルカメラ、キーボード、マウス、ゲームコントローラなど。USB機器はAndroid専用というわけではなくAndroid環境でも使用できる機器というだけで、正しくその機器と通信するように設計されている。
どちらのモードもAndroid 3.1(APIレベル 12)以降でサポートされる。USBアクセサリモードはAndroid 2.3.4(APIレベル10)でもアドオンライブラリでサポートされる。デバイスを作る人はライブラリあり/なしを選べる。

とにかく、ライブラリでサポートされるようだ。
しかし、うちのSDK Managerには2.3.4が出てこなかった・・・。
まあ、慌てなくていいんだけどね。



2011/12/29追記

市販のAndroid端末でUSBアクセサリモードが動かない場合、ADK側のソースをいじると動くかもしれない。
http://hiro99ma.blogspot.com/2011/12/accessory-modevid.html

[felica]USIMが入っていないとアクセスできないようだ

私はドコモのP906iを使っている。
何となく気になって、USIMなしの状態でFeliCaがどうなるのかやってみた。
といっても、Suicaみたいなサービスは使ってない(使えない)ので、PaSoRiで試しただけだ。
  • ポーリングはできる
  • Suica残高は見えなかった(\0、すら出てこない)
これだけしか試してないが、そういうことなのだろう。
しかし・・・どうやって実現しているのだ?
ポーリングができるということは、FeliCaロックのルートではないことになる。
となると、セキュアエレメントか。
USIMが適切ではないので、FeliCaチップとセキュアエレメント間を断ち切ったのだろう。
あるいは、セキュアエレメントロック、みたいな機構を使ったとか。
そっちの方が簡単そうだな。
起動時にUSIMチェックをして、不適切ならロックする、と。
まあ、推測でしかないんだけどね。

2011/05/09

[paintshoppro]オブジェクトの結合はできないようだ

Paint Shop Pro、というツールがある。
仕事で画像を加工するのにいいツールを探していて、一番安かったので購入したことがある。
その後、家でも画像を加工するツールを探していたら、PaintShopProが安かったので、購入。
ペイント系の絵を描くのには、困っていない。
まあ、そんなに大した絵を描くこともないし、写真の加工をするわけでもないし。
ただ最近、Android用に何かを描こうとすると、画面サイズごとに画像を用意したりする。
そのとき、ペイント系だと非常にめんどくさい。
ベクタ系でも描けるようにならないと、と思い始めたのだ。
Paint Shop Pro(私は9を使っている)は、ベクタ系も使える。
慣れるために使っているのだが、一つ困ったことが起きた。
どうも、オブジェクトを結合することができないようなのだ。

順に説明する。
Paint Shop Proでは、ベクタで描いた図形のひとまとまりを「オブジェクト」と呼ぶ。
簡単に言えば、楕円ツールで描いたら、それ1つ1つがオブジェクト。四角ツールで描いたら、それはそれで1つ1つがオブジェクト。
私がやりたかったのは、2つの楕円がつながった図形を作ること。
それだけなら、楕円を描いて重ねればいい。
ついでにやりたいのは、重なった図形を「同じように扱いたい」ということ。
例えば「塗りつぶし」とやると、2つとも同時に塗りつぶしてほしい。
線の色を変えたら、同時に変更してほしい。
となると、結合という動作をしたいことになると思った。
Paint Shop Proのメニューに「結合」というものがあったので、ヘルプで検索。
そうすると・・・「同じオブジェクトにしか使えません」とある。。。
つまり、そういうことらしい。
1つのオブジェクトとして描いたものでなければ、結合ができないのだ。
この「結合」というのは、オブジェクトを構成する要素を組み替えたりするときに使うもの。
残念ながら、私がやりたいことは簡単にはできなさそうだ。
楕円ツールではなく、線を描くツールで描いていけば、1つのオブジェクトとして認識してくれるのだ。
だけど・・・そこまでしたくはない。楽したいのだ。
ならば違うツールを・・・。
そう思ってGIMP2をインストールしてみた。
むかーし試してみて、よくわからんかったんだよな。
そしてもちろん、今回もわからず・・・。
あれだな、アイコンの意味がわかってないからだな。
しばらく、ベクタはGIMPで描いてみようか。

2011/05/05

FeliCa Liteの片側認証はこうなのか?

IDmは、唯一性を保証してくれない。
どこかで重なる数値が出てくるかもしれないし、R/Wであれば意図的にIDmを作り出すこともできる。

R/Wのこの仕様は、もう少し変更した方がよかったのではないかと思っている。
Type-Aは4byteタイプしか作り出せず、しかもそのうちの3byteしか指定できないと思うからだ(PN533では)。
いろいろと事情はあるのかもしれないけど、私はそんなに知らないのだ。

それはいいとして。
どうやって偽カードから守るかを考えなくてはならない。
FeliCa Liteカードの場合、それは「片側認証」という手順を用いるようだ。
これは別に秘密でもなんでもなく、ダウンロードできる資料に書かれている。
以下は、私の認識でしかないので、各人調べてほしい。


発行

サービス事業者は、カードを発行するときに、

  • ID
  • カード鍵

をカードに書き込んでから渡す。


認証

サービス事業者がR/Wを用意し、それとカードがやりあう。

まずR/Wが乱数を発生させ、それをカードに書き込む。
この乱数は「ランダムチャレンジブロック」に書き込まれる。

次に、IDブロックとMACブロックを読み込む。
このときMACブロックには、ランダムチャレンジ値とカード鍵値を元にしてIDブロック値から生成したMACが返ってくる。
サービス事業者は、IDブロック値さえあれば、カード側が生成するMACと同じ値が作り出せるはずである。
なぜなら、MACの計算方法は指定されていて、そのパラメータはすべて取得するか、事前にわかっているからだ。
最後にサービス事業者は、自分で生成したMAC値と、読み取ったMAC値が等しいことを確認し、認証を終える。


なぜこの手順で認証できるのか?
MACの計算方法がわかるのであれば、偽カードでも同じことができるのでは?

では、簡易的な偽カードソフトを作ったと仮定して考えてみよう。


カードを発行するまでは、同じ。

その後、悪い人が間に入ってくる。
R/WでFeliCa Liteカードの中身を全部読み取ってしまえ!

IDm、PMmはもちろん、スクラッチパッドの中身なんかも読み取ることができてしまう。
あやうし、FeliCa Liteカード!!

さて、悪い人はソフトを作り、読み取ったIDmとPMm、システムコードなんかもPollingで返すように作ってしまう。
Read Without Encryptionでスクラッチパッドのブロックを指定されても、それを返すようにしてやればいい。
しめしめ、これで完璧だ。。。


しかし安心してほしい。
読んだときに、書き込んである値を返さないレジスタがある。
それがMAC値を作るときに使う、ランダムチャレンジ値とカード鍵値だ。

ランダムチャレンジブロックはR/Wから与える方なので、その場にならないとわからない。
読み取るなら、アクセスするその場にいなくてはならない。
通常なら、そんな不審な人はだめだろう。


では、R/Wを奪い取ったとしよう。
そしたら、何度でも試せるではないか。
しかし…だ、ランダムチャレンジブロックへのアクセスはR/Wから行うものの、カード鍵へのアクセスは行わないのだ。
行っても、値が取れないし。
だから、簡単にはMAC値を作り出すことができない。

やるとするなら、認証ソフトも自分で作って、ランダムチャレンジブロックへの書き込み値を一定にして、同じMAC値が返ってくるカード鍵値を求める、というくらいだろうか。
カード鍵さえわかれば、ランダムチャレンジブロックは毎回変化するのでどうでもいい。
自分で認証ソフトを作り、繰り返すだけでいいのだ!


もはやここまでか、と思ったが、なかなかそうもいかない。

ここらへんで、3DESという暗号が出てくる。
残念ながら、私は暗号化に詳しくない・・・。
昔読んだゴルゴ13に、簡単にするためにこんな説明があった。

  a^2 + b^2 = c

という場合、aとbがわかればcはすぐに出てくるけど、cがわかってもaとbはなかなか割り出せない、とか。
何となくいわんとするところはわかる。
まあ、この説明がどの暗号化に対してだったか知らないのだけど。。

今回のような悪事を働いた場合、aとcは出てくるので、bだけであればそんなに難しくない。
しかし3DESは一昔前までは最前線だった暗号化だから、そう易々と解析できないのではなかろうか。


これは、FeliCa Liteカードの話で、FeliCaカード(FeliCa Standardカード)のことではない。
あくまで廉価版なので、セキュリティは弱めなのだ。
なので、非常に大変な情報(お金とか)を扱うのであれば、FeliCa Liteカードは不向きである。

FeliCa Standardカードの場合は、さらに頑強になっている。
のかどうかはわからないが、少なくともFeliCa Liteよりもやれることが多いので、頑強にできるはず。

FeliCa Liteだって、カード鍵がわかって偽造方法がわかったとしても、影響は同じカード鍵を使っている範囲に限られる。
それにIDmの書き換えは一部のバイトしかできないようなので、そうそう同じIDmにはできない。
やるならR/Wが向いているけど、店でカードじゃなくてR/Wをかざすような人には「ちょっとお客様、こちらへよろしいですか?」と尋ねるくらいの指導はしてほしいものだ。

やっぱり、人間に向いた作業ってのはあるのよねー。

2011/05/04

どうやって私はRC-S620/Sを壊したか

RC-S620/Sが動かなくなったので、スイッチサイエンス社に注文していた。
その品が、今日届いた。

もしかすると、RC-S620/SからPCにつなぐまでの経路が壊れたのかも、と期待したのだが、だめだった。
差し替えると動く。
あちゃー。
やってしまった。。。。


さて、私は何をして壊してしまったのだろうか?

原因は、逆接続だと思う。
付属のコネクタがピン折れしてしまったので、変換基板を購入していたのだ。
あまり考えずに接続していたのだが、落とし穴があった。

それは、変換基板に書いてある1~6ピンと、RC-S620/Sの1~6ピンが逆になっていることだ。
それに気付かず、動かんなー、動かんなーとしばらくやっていたのだよ。
ちょっとだけだったらよかったかもしれないけど、逆と思っていなかったので長いことやってたんだよなぁ。

なんかもう、甘く見ていた、ということに尽きる。
RC-S620/Sが温かいなとは思ったのだが、チンチンになってなかったので安心していたのだ。

配線を確認してから通電しなさい、という基本を怠ったことに対する手痛い教訓だ。