scriptcmd適用するたびにファームをアップデートしてしまうのはとっても無駄。
Wifiの設定や解析用アプリを入れなおすだけでも時間の無駄なので、scriptcmdの環境変数初期化部分だけ抜き出して適用することにした。
今のところ、、、、問題ないみたい。
おｋｗ
これで自由に切り替えられる(^^)
と言うわけで、置いときます。
※何が起こっても知りません（・∀・）
scriptcmd.env.bt.wifi.cam.1.7.4
bluetooth_ui, camera_ui, Wifiキレテナーイ適用
scriptcmd.env.bt.wifi.hw.cam.1.7.4
bluetooth_ui, camera_ui, enable_hw_scal, Wifiキレテナーイ適用
scriptcmd.env.wifi.all_ui.1.7.4
色んなUI, enable_hw_scal, Wifiキレテナーイ適用
※数分放置で勝手にリブートしちゃう。とっても不安定。
使い方は、
SDカードにscriptフォルダ掘る。
その中にお好みのスクリプトを scriptcmd にリネームしていれる。
M001に刺す。
電源ON。
環境変数だけアップデート実行（数秒）
画面にメッセージが出たらSDカードを抜いて再起動。
以上。
ところで、enable_hw_scalって何？
/system/lib/libwmtmedia.so
内で初期化されているパラメータ。
WM特有のライブラリなので、WM CPU専用と思われる。
中を少し見ると、MJPEGハードウェアデコーダで使用されるパラメータらしい。
変数名から察すると、ハードウェアスケーラーを有効化するものか？
よくわからんけど、面白い事ができればいいなぁ。
2010年6月29日火曜日
2010年6月24日木曜日
1.7.4用scriptcmd他
Original Firmware 1.7.4用のscriptcmdを置いときます。
（´・ω・｀）つ旦 どぞ
ちなみに、ファームバージョン違いのscriptcmdを使用してはいけない。
文鎮になるかもよ（つД｀）
さて、
1.7.4をいじってみて、一通り楽しんだ。
色々追加されてて進化してるのがわかる。
scriptcmdの中に謎のUIフラグがあったりなかったり。
有線LANのUIはちゃんと生きてるようで、設定もできるっぽい。
で、root化してswapも動く。
ところで、Marketが変だ。
サインインして最初、ダウンロードができたけど、しばらくすると見覚えの無いダウンロード通知が来て何が何だかさっぱりｗ
そして、なぜかダウンロードできなくなる有様。
（・ω・？
フォーラムを見てみると、なにやら他人のダウンロードが飛んできてるような感じがする。。。。
Marketの認証情報、世界中で共有ですか？？ｗ
ちっともダウンロードできない。
変な実装しやがって。
（つД｀）ばかちーん！
（´・ω・｀）つ旦 どぞ
ちなみに、ファームバージョン違いのscriptcmdを使用してはいけない。
文鎮になるかもよ（つД｀）
1.7.4をいじってみて、一通り楽しんだ。
色々追加されてて進化してるのがわかる。
scriptcmdの中に謎のUIフラグがあったりなかったり。
有線LANのUIはちゃんと生きてるようで、設定もできるっぽい。
で、root化してswapも動く。
ところで、Marketが変だ。
サインインして最初、ダウンロードができたけど、しばらくすると見覚えの無いダウンロード通知が来て何が何だかさっぱりｗ
そして、なぜかダウンロードできなくなる有様。
（・ω・？
フォーラムを見てみると、なにやら他人のダウンロードが飛んできてるような感じがする。。。。
Marketの認証情報、世界中で共有ですか？？ｗ
ちっともダウンロードできない。
変な実装しやがって。
（つД｀）ばかちーん！
2010年6月20日日曜日
scriptcmd.wifi_powerdown
2010年6月16日水曜日
Wifi offでもキレテナーイ
おもちゃ(M001)にウィジットのカレンダーやらメモやら張ってたらどんどん重くなって、昨日、なぜか戻るボタンが利かなくなった。
やりすぎたか・・・（´∀｀；
仕方ないので、ファームを一から入れなおしてるときに気が付いた。
こんなところにデバイスon/offの隠しコマンドが入ってた。
そういや、玄箱いじってたときに同じようにu-Bootでカーネルパラメータ渡してたなぁ～と、いまさら気付いたわ。
てか、その他の環境変数を眺めてみると、ぞろぞろとデバイスコントロールの変数が格納されているようだ。
こいつらは、ファームのアップデート処理の段階でsetenvされた後、saveenv、つまりM001内蔵のフラッシュメモリに格納され保存される。
ファームのアップデート処理が終わり、普段どおりu-Bootからカーネルが起動していくと、格納されているものが読み込まれる。って按配。
で、書いてある通り、
GPIO : 0xD81100B4 の 0x4 ビットを立てると内部USBが活性化。
0x4ビットを寝かせるとUSBが切れる。
あとは簡単。
wifi_powerdown のときでも0x4ビットを立てっぱなしにすればいい。
環境変数領域を直接読み書きする方法が分からなかったので、scriptcmdを作り直してアップデータを利用する。
修正した内容でテキスト記述したコマンドファイルを作り、
Linux上で mkimage して scriptcmd を作り直した。
SlateDroidの記事を参考にmake。
Win用のmkimageがあればそれでもいいと思う。
で、、、
ファームを再インストールｗｗ
めんどくせー(笑)
でも、、、、、
ばっちりｗｗ
wifi offでもUSB切れませーん＼(^o^)／
でも、wifiへの電源供給は続くって事なのでバッテリを食う。
実際には、ネットワーク自体は繋がってないからいいんだけど。
ログの様子。
え？フライトモード？？
フライトモードなんてただの飾りです。
偉い人にはそれがわからんのです。キリッ。
これで、USBメモリもキーボードも切れる事が無くなった。
今なんかこんな感じ(^_^;
ところで、
やりすぎたか・・・（´∀｀；
仕方ないので、ファームを一から入れなおしてるときに気が付いた。
scriptcmd中を覗くと、
setenv wifi_powerdown D8110064|0x4,D811008C|0x4,D81100B4&~0x4( ゜д゜)・・・おまえかっ！！
setenv wifi_powerup D8110064|0x4,D811008C|0x4,D81100B4|0x4
＜略＞
saveenv
こんなところにデバイスon/offの隠しコマンドが入ってた。
そういや、玄箱いじってたときに同じようにu-Bootでカーネルパラメータ渡してたなぁ～と、いまさら気付いたわ。
てか、その他の環境変数を眺めてみると、ぞろぞろとデバイスコントロールの変数が格納されているようだ。
こいつらは、ファームのアップデート処理の段階でsetenvされた後、saveenv、つまりM001内蔵のフラッシュメモリに格納され保存される。
ファームのアップデート処理が終わり、普段どおりu-Bootからカーネルが起動していくと、格納されているものが読み込まれる。って按配。
で、書いてある通り、
GPIO : 0xD81100B4 の 0x4 ビットを立てると内部USBが活性化。
0x4ビットを寝かせるとUSBが切れる。
あとは簡単。
wifi_powerdown のときでも0x4ビットを立てっぱなしにすればいい。
setenv wifi_powerdown D8110064|0x4,D811008C|0x4,D81100B4|0x4で、、、、
環境変数領域を直接読み書きする方法が分からなかったので、scriptcmdを作り直してアップデータを利用する。
修正した内容でテキスト記述したコマンドファイルを作り、
Linux上で mkimage して scriptcmd を作り直した。
SlateDroidの記事を参考にmake。
mkimage -A arm -O linux -T script -C none -a 0 -e 0 -n 'wifi never off' -d scriptcmd.txt scriptcmdたまたま、VMwareなubuntuを入れてたのでサクッと。
Win用のmkimageがあればそれでもいいと思う。
で、、、
ファームを再インストールｗｗ
めんどくせー(笑)
でも、、、、、ばっちりｗｗ
wifi offでもUSB切れませーん＼(^o^)／
でも、wifiへの電源供給は続くって事なのでバッテリを食う。
実際には、ネットワーク自体は繋がってないからいいんだけど。
ログの様子。
wifi power up:D8110064|0x4,D811008C|0x4,D81100B4|0x4
gpio op: 0xD8110064 | 0x4
gpio op: 0xD811008C | 0x4
gpio op: 0xD81100B4 | 0x4
wifi power down:D8110064|0x4,D811008C|0x4,D81100B4|0x4
gpio op: 0xD8110064 | 0x4
gpio op: 0xD811008C | 0x4
gpio op: 0xD81100B4 | 0x4
え？フライトモード？？
フライトモードなんてただの飾りです。
偉い人にはそれがわからんのです。キリッ。
これで、USBメモリもキーボードも切れる事が無くなった。今なんかこんな感じ(^_^;
ところで、
setenv hibernation_ui noこれナニ？
2010年6月15日火曜日
Wifi offでUSBが使えない件
ハードウェアやOSの動きを調べるのに、カーネルが吐き出すdmesgログを読むと色々分かったりする。
M001のdmesgにも色々吐き出されてておもしろい。
バイブレータドライバをロードしてたり、有線のGigabit Ethernetドライバが動いてたり、PS/2ポートが生きてたり、initでいらんコマンド動かしてたり。
手がかりを探すにはもってこいの資料だったりする。
で、Wifiをon/offしたときのログ。
Wifi onにすると、gpioを使ってCPU内部のコントローラ状態が変更される。
それが2～4行目。
んで、rt2870用のドライバ（rt3070だけどね）が登録され使用できるようになる。
と、同時にUSB機器が認識され始める。
このときの、USB機器の接続状態はこんな感じ
次に、その先に繋がってるデバイス address 3 と 4 が見つけられているのが分かる（WifiとUSBメモリ）
次に、Wifi off のときのログ
すると、勝手に address 2 （埋め込みHub）が disconnect になり、自動的にその先にぶら下がっているデバイス、address 3, 4 も disconnectになる。
これが、Wifi offにするとHubにぶら下がってる他のデバイスが使えなくなる原因。
on/offのシーケンスを考えるに、
事前に実行される gpioのコントローラ状態変更がキーになってるっぽい。
あるビットをマスクすることで、内部のUSBコントローラをスリープにしてしまうのかもしれない。
うーん、、、困ったな。
探したんだけど、、、
見つからない。（´・ω・｀）
M001のdmesgにも色々吐き出されてておもしろい。
バイブレータドライバをロードしてたり、有線のGigabit Ethernetドライバが動いてたり、PS/2ポートが生きてたり、initでいらんコマンド動かしてたり。
手がかりを探すにはもってこいの資料だったりする。
で、Wifiをon/offしたときのログ。
wifi power up:D8110064|0x4,D811008C|0x4,D81100B4|0x4一部省略してる。
gpio op: 0xD8110064 | 0x4
gpio op: 0xD811008C | 0x4
gpio op: 0xD81100B4 | 0x4
usbcore: registered new interface driver rt2870
usb 1-1: new high speed USB device using ehci_hcd and address 2
usb 1-1: configuration #1 chosen from 1 choice
hub 1-1:1.0: USB hub found
hub 1-1:1.0: 4 ports detected
usb 1-1.3: new high speed USB device using ehci_hcd and address 3
usb 1-1.3: configuration #1 chosen from 1 choice
usb 1-1.4: new high speed USB device using ehci_hcd and address 4
usb 1-1.4: configuration #1 chosen from 1 choice
Wifi onにすると、gpioを使ってCPU内部のコントローラ状態が変更される。
それが2～4行目。
んで、rt2870用のドライバ（rt3070だけどね）が登録され使用できるようになる。
と、同時にUSB機器が認識され始める。
このときの、USB機器の接続状態はこんな感じ
WM8505内蔵コントローラ最初に、埋め込みHubが address 2 として見つけられ、USB hub found. 4 ports detected されている。
+----> 埋め込みHub
+----> rt3070(Wifi)
+----> USBメモリ
次に、その先に繋がってるデバイス address 3 と 4 が見つけられているのが分かる（WifiとUSBメモリ）
次に、Wifi off のときのログ
wifi power down:D8110064|0x4,D811008C|0x4,D81100B4&~0x4同じく、gpioを使ってコントローラの状態を変更している。
gpio op: 0xD8110064 | 0x4
gpio op: 0xD811008C | 0x4
gpio op: 0xD81100B4 & 0xFFFFFFFB
- rtusb exit
usb 1-1: USB disconnect, address 2
usb 1-1.3: USB disconnect, address 3
usb 1-1.4: USB disconnect, address 4
すると、勝手に address 2 （埋め込みHub）が disconnect になり、自動的にその先にぶら下がっているデバイス、address 3, 4 も disconnectになる。
これが、Wifi offにするとHubにぶら下がってる他のデバイスが使えなくなる原因。
on/offのシーケンスを考えるに、
事前に実行される gpioのコントローラ状態変更がキーになってるっぽい。
あるビットをマスクすることで、内部のUSBコントローラをスリープにしてしまうのかもしれない。
うーん、、、困ったな。
wifi power up:D8110064|0x4,D811008C|0x4,D81100B4|0x4と
wifi power down:D8110064|0x4,D811008C|0x4,D81100B4&~0x4実際にこの処理をどこかで行っているハズ。
探したんだけど、、、
見つからない。（´・ω・｀）
登録:
投稿 (Atom)