no vmaについて少し検索すると、アクセス権が足りてない、というような記述がちょっとあった。
では、ちょっと試してみよう。
$ chmod 0777 -R data
だめ。
$ chmod 0777 *
だめ。
$ chmod -R 0777 *
だめ。
というわけで、今回はアクセス権の問題ではないようだ。
次いってみよう。
ASHMEMがないんじゃないの、というのもあったが、それは大丈夫だ。
ashmem: initialized
2011年5月31日
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時半までに寝る」を設定してしまったので、寝よう。
昼間が眠いのよ。。。
「どうせデフォルトで/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年5月30日
同じバージョンなのにいままでのと全然違う
今まで使っていたkernelと、rowboatのkernel。
バージョンはどちらも2.6.32。
ならば移植は簡単だろうと思っていたのだが・・全然だめだ。
drivers/usbを置きかえ、コンパイルエラー。
では、とinclude/linux/usbも置きかえ、やっぱりコンパイルエラー。
あちこちつぎはぎして、今度はttyエラー。
「これではビルドが通っても正しく動かないかも」と思うような修正をしたら、今度はi2cが。
ヘッダのファイル名が変わってるし、APIも追加されてる。。。
というところで、今一息ついたところだ。
同じものでは・・・ないのか？
違うといえば、バージョンも正確には、2.6.32.9、となっている。
この「.9」がこの差を生んでいるのだろうか。
うーん、我慢強い方だと思っていた私だが、さすがに音を上げそうだ。
rowboatベースでDisplayLinkを動かせるようにした方が早いのかもしれない。
試しにやってみるか。
バージョンはどちらも2.6.32。
ならば移植は簡単だろうと思っていたのだが・・全然だめだ。
drivers/usbを置きかえ、コンパイルエラー。
では、とinclude/linux/usbも置きかえ、やっぱりコンパイルエラー。
あちこちつぎはぎして、今度はttyエラー。
「これではビルドが通っても正しく動かないかも」と思うような修正をしたら、今度はi2cが。
ヘッダのファイル名が変わってるし、APIも追加されてる。。。
というところで、今一息ついたところだ。
同じものでは・・・ないのか？
違うといえば、バージョンも正確には、2.6.32.9、となっている。
この「.9」がこの差を生んでいるのだろうか。
うーん、我慢強い方だと思っていた私だが、さすがに音を上げそうだ。
rowboatベースでDisplayLinkを動かせるようにした方が早いのかもしれない。
試しにやってみるか。
kernelを変更して困ったことが２つ
さて、adbも動いたし、あとはAPPを載せて動作確認するだけ、と思ったが、そうはいかなかった。
今まで使用していたkernelからrowboatのkernelになったことで、困ったことが２つ出てきたのだ。
１つは、mediaserverが再起動を繰り返すようになったこと。
差分がどこにあるか分からないけど、init.rcとかasound.confあたりで済めばありがたい。
それにまあ、再起動しているだけなので、無視していればいい、ということもある。
問題は２つめだ。
DisplayLink側に表示してくれない。
起動すると画面が1色で塗りつぶされているので、ドライバの初期化は呼ばれている。
しかし、そこから変化なし。
おそらく、強制的にDVI側に出しているんじゃないだろうか。
まいったなぁ。。。
TIのAndroid環境は以下の特長があるとかかれている。
The following features from previous release are provided:
このあたりが影響を受けているような気がする。
それならいっそのこと、Android環境もTIのものに置き換えればいいのだがちょっと気力が沸かない。
TIの環境が劣っているとか、そんなことはないのだ。
むしろ優れている。
いやがっているのは、せっかくgithubで作ってきた環境がつかえなくなること。
OESFさんの環境をcloneしているのを、rowboatさんので置きかえていけばいいんだろうけど、repoでとってくるタイプになるので、全部cloneしていくのがめんどくさい。
うーん、どうしたものか。。。
今まで使用していたkernelからrowboatのkernelになったことで、困ったことが２つ出てきたのだ。
１つは、mediaserverが再起動を繰り返すようになったこと。
差分がどこにあるか分からないけど、init.rcとかasound.confあたりで済めばありがたい。
それにまあ、再起動しているだけなので、無視していればいい、ということもある。
問題は２つめだ。
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年5月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ベースらしい。
そうか、そっちを見ていくのがいいんですな。
ありがとうみなさん、また一つ勉強しました。
環境としては、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環境があった。
そんなものが！
・・・いや、以前にも目にしたことがあるのだが「自分でやるんだ！」と切り捨てていたのだ。
ああ、私にはまだ先生が必要なのですな。
しかし、今回は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。
そう、ようやくアドレスが取得できたのだ。
もう２つ先まで載せよう。
<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関係の設定が出てこなかった。
他にも関係あるのかもしれないが、これで続けてみよう。
そのソースが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。
そう、ようやくアドレスが取得できたのだ。
もう２つ先まで載せよう。
<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の掲示板はスパムしか目に付かず、本当に内容があるものはごくわずかだからだ。
２月の投稿で、Coviaの人が「今月中にはcode.googleにソースをアップできます」みたいなことが書かれていた。
ソースファイルが出たなんていうアナウンスはなかったような・・・と検索すると、あった。
http://code.google.com/p/covia-opensource-smartq5-android-froyo/
えー、もうちょっと大きくアナウンスしてくれよ～。
あるいは・・・偽物なのか？？
わざわざ偽物を作るほどのものではないと思うが、そう思わせるのも作戦のうちとか。。。
twitterにはアナウンスされてた・・・。
ひどい。。。掲示板に書いたものは掲示板でアナウンスしてくれよ。。。
どういうことかというと、SmartQ5の掲示板はスパムしか目に付かず、本当に内容があるものはごくわずかだからだ。
２月の投稿で、Coviaの人が「今月中にはcode.googleにソースをアップできます」みたいなことが書かれていた。
ソースファイルが出たなんていうアナウンスはなかったような・・・と検索すると、あった。
http://code.google.com/p/covia-opensource-smartq5-android-froyo/
えー、もうちょっと大きくアナウンスしてくれよ～。
あるいは・・・偽物なのか？？
わざわざ偽物を作るほどのものではないと思うが、そう思わせるのも作戦のうちとか。。。
twitterにはアナウンスされてた・・・。
ひどい。。。掲示板に書いたものは掲示板でアナウンスしてくれよ。。。
2011年5月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トークンパケットが来た後だ。
１８byteって大きいから、ハンドシェークパケットではなさそうだ。
<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設定にしてみたが、特に変化なし。
うーむ。。。。。。。
わからないときは、現場に戻るべし。
カーネルのログを見てみよう。
<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トークンパケットが来た後だ。
１８byteって大きいから、ハンドシェークパケットではなさそうだ。
<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させない、とすると・・・同じだった。
うーん、どうもそういう問題ではないようだ。
<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させない、とすると・・・同じだった。
うーん、どうもそういう問題ではないようだ。
登録:
投稿 (Atom)