365
kernel書き換え試してみるのはとりあえず、自己リスクで。
/system書き換える場合も、androidを起動しなくても
adbがつながるようにしてからやるのが安心だと思います。
現状androidが起動しない&adbでつながらないときに元に戻す
手段がないので危険だと思います。
現在bootloaderにそういったモードがないか確認中です。
自分の場合はandroid起動しなくてもadbでつなげられるのですが
qxdmを有効にした状態ですので、もしadb認識してない人は
qxdmを有効にしてみてください。
echo 1 > /sys/devices/platform/msm_hsusb_periphera/qxdm_enable
407
戻りました。bootloader解析続けます。
文鎮状態の人を大量発生させるのはいやなので。^^;
412
/dev/mem, /dev/kmemの代わりをするドライバを起こしました。
/dev/mem_ex, /dev/kmem_exが使えます。
http://hotfile.com/dl/86203816/abbea85/mem_ex.zip.html
./mem_ex 20008000 100 | /data/bootkit/busybox hexdump -C
こうすると、物理アドレス0x20008000 から 0x100バイトダンプできます。
不安定のため、テスト版ということで。後ほどソースUpします。
たとえば、
cat /proc/kallsyms | /data/busybox/grep kstrtab_jiffies_64$
804cd1a8 r __ksymtab_jiffies_64
./mem_ex 204cd1a8 4 | /data/busybox/hexdump -C
00000000 a8 e5 4f 80
00000004
./mem_ex 204fe5a8 4 | /data/busybox/hexdump -C
これで、jiffiesがダンプで着ます。
432
bootloader内に、リカバリーモードに移行するモードがあるのを発見
現在方法解析中
743
以前に質問があがっていた、URA_MODE指定でのbootが
できるようにしてみました。
手元に実機がないので、なんともいえないですが・・
insmodした後に、
cat /proc/reboot_fastboot
でfastbootの起動にtryします。
cat /proc/reboot_uramode
でuramodeの起動にtryします。
http://hotfile.com/dl/87649426/0077814/shdiag_test.zip.html
URA_MODEって何なんでしょうね・・
745
>>743 お疲れ様です。
cat /proc/reboot_fastboot
cat /proc/reboot_uramode
両方とも、通常起動してきます。
よろしければ、私も合同デバッグに参加したくおもいます。
746
オリジナルのブートローダですが、のっとるのは無理そうでした。
ダウンロードモードでファームウェアを更新するほうも、
xperiaのようにまずダウンロード用のbootloaderを転送してから
実際の書き換え処理をしなければいけなく、手間が多いので
ちょっとこの辺できりにしようと思ってます。
747
一応解析した結果は後ほどまとめておきますね。
いづれにしても文鎮化対策は必要だと思いますので、
kernel&system,recoveryが壊れたときにもリカバリできる手段を考えます。
いまのところは、オリジナルのブートローダからの起動に
さらに自家製ブートローダを挟み込み、あるキーが押されて
起動されたときは、自家製ブートローダ＋fastbootでNANDが
書き換えられるような方向で考えています。
750
どなたか。
こちらをrecovery領域に焼いて、fastbootが起動するか確認お願いできますか？
http://hotfile.com/dl/87692648/6ca0cd3/mtd2.zip.html
reboot recoveryでfastbootに移行します。
画面上には変化は出ませんが、新しいUSBが認識すると思いますので、
そこで、sdkに付属のusbドライバ、android_winusb.infを変更して、
SingleBootLoaderInterfaceとして認識するようにVendorID, ProductIDをあわせてください。
認識後は、
fastboot -i 0x4dd getvar version
ができると思います。
ちょっとできるかどうか確認お願いできますか？
752
>>750
# flash_image recovery_rw /sdcard/tmp/mtd2bin 実行後
> adb reboot recovery で端末が再起動しますが
"IS series" のロゴのまま進みません。3分ほど放置。
一旦、電池抜いて通常bootで起動はできました。
753
>>752
ロゴがでっぱなしで動いているように見えないのは仕様です。
その状態でUSB認識しますでしょうか？
754
adb からは device not found
windows 上からは USB デバイス認識していないように見えます。
> デバイスマネージャーから Android Phone が見えない。
> 不明なデバイス等は見当たらない
android_winusb.info は書き換えていません。
755
>>752
カーネルのスタートコードにいきなりリターン命令を入れてみたのですが、
うまくいかないですね・・。
引き続き見てみます。
772
JN-DK01では、fastboot modeはトラックボールを押しながら電源をONします。
他のandroidでも、何かを押しながら電源ONでモードに入ることが多い見たいですが
IS01にはボタン等を押しながら電源ONでfastboot modeする方法はないとか、
fastboot mode自体ないと解析の結果でたのでしょうか？
773
>>772
その通りで、ボタンからはfastboot,recoveryに入る方法はない可能性が大です。
少なくてもfastbootには入れません。
以前にbootloaderのバイナリ&アセンブラソースはあげましたが、もう一度あげておきます。
http://hotfile.com/dl/87926737/33050a5/is01_bootloader.zip.html
is01でも同じようにトラックボール押しながら電源ONでfastboot要求自体は
入るのですが、
is01ブートローダーはmain関数内で、fastbootに入るかどうかのチェックを
無視するようにパッチがあたっています。
775
>>773
ブートローダを書き換える方法はありそうですか？
786
>>773
というとトラックボール押しながら電源ONでboot recoveryという設定にすることは可能なのでしょうか？
792
>>775
モデム側のファームウェアにあるダウンロードモードであれば可能と思われますが、
根が深く調査は困難です。HTCのようなQualcomm互換のものではないので。
現状はブートローダーは書き換えない方向で考えています。
>>786
トラックボール押しながらの操作はモデム側のファームウェアでfastboot用の
フラグは立てていますが、Recoveryモード用のフラグは存在しなさそうでした。
キー操作でRecoveryにするのは絶対とは言えませんが無理な可能性が高いです。
なので、これらの方向から攻めるのはいったんキリにしようかと思っています。
ちなみに、IS01のキーボードはモデム側のファームウェアで管理されており
I2Cというバスでつながっています。４つまでのキーの同時押しに対応している
ようです。
817
>>773
bootloaderのバイナリ&アセンブラソース拝見しました。
もし、usbloader動くとvendor idが18D1、product idがD00Dとなるのでしょうか？
18D1ってシャープではないですよね。
他のベンダーID使っていいわけではないと思うので動かないことを前提で放置だったのかな。
android_winusb.infの修正は、SingleBootLoaderInterfaceとして
VID:18D1、PID:D00Dを追記なのでしょうか？
819
>>817
www.linux-usb.org/usb.ids
18D1はGoogle Inc.で、PIDには
4e11 Nexus One Phone
4e12 Nexus One Phone (Debug)
4e13 Nexus One Phone (USB Tether)
がある
818
is01用のmkbootimg作れた人います？
ソースは落としたものの、makeが出来ない・・・
できればバイナリをアップしてもらえると嬉しいのですが・・・
応援スレにあげたんですけどスレチな気がしてこっちに書き直しました。
820
>>818
助けが欲しいならもうちょっと詳しく書くべき
こっちではmkbootimg.cにsha.c sha.hをインクルード後gccで正常�コンパイル出来てる
もうちょっとまともなやり方もあるとおもうけどね
821
>>818
http://hotfile.com/dl/88199283/527d4cd/mkbootimg.html
CM版なので、こんな感じで使います
./mkbootimg --kernel kernel.bin --ramdisk ramdisk.bin --cmdline "console=ttyMSM2,115200n8 androidboot.hardware=qcom" --base 0x20000000 --ramdiskaddr 0x04000000 --pagesize 0x1000 -o boot.img
822
IS01でとりあえず動作する bootloderのソースとバイナリです。
JN-DK01ではusb認識するのですが、IS01だと認識せず。
ただし、画面にコンソール出力ができるようになったので
デバッグはできると思われます。
http://hotfile.com/dl/88205875/33a5b88/is01_fastboot20101209.tgz.html
632
まずはsystemがマウントできなくてもadb shellでつながるように見るのが先決と思われます。
まずは、recovery領域で・・
default.propとinit.rcを書き換え、adbを電源ON時に起動するようにする。
/sys/devices/platform/usb_periphera/qxdm_enableに1を書き、adbが
電源ON時に有効になるようにする。(ここは、kernelを書き換えてqxdmが有効でなくても
初期をadb接続にするのも手)
adbのソースをいれかえて、/system/bin/shではなく、/sbin/shあたりから起動するようにする。
/sbin/の下にbusyboxやそれにシンボリックリンク張られたshを用意
これで、systemがマウントできなくてもadbでとりあえずつながるようになるので、
まずこの環境を用意するのがよいと思います。
720
boot領域に焼いていれば復旧するカーネルができたっぽい。
NVさんありがとうございます。
http://www.megaupload.com/?d=T63HMVRO
既出だったらごめん。
746
誰か>>720試した？
749
>>746
NVさん自身がそのことを書いているのが見当たらない。
>boot領域に焼いていれば復旧するカーネルができたっぽい。
これをどう解釈していいのやら。
750
>>749
ついったーにあるよ
754
>>746
入れたよ
まだsystemまで到達してないからなんとも言えないけど
入れた結果変な挙動なるってことはなさそう
771
recovery_kitは、boot領域に焼いて意味があるものです。
recovery領域に焼いても、現時点ではboot領域を通る必要があるので意味がないです。
929
recovery_kit v1.20を公開。
リカバリメニューを追加しました。
また、自動ブートを追加したので、必要なときだけリカバリメニューを使うことができます。
http://www.megaupload.com/?d=YGH8MHY1
12
recovery_kit v1.25を公開。
起動画面の変更と、adbdを自動起動に戻しました。
http://www.megaupload.com/?d=3LFMY78G
36
Recovery_kit書き込むやつが多いが、Boot領域に書き込むリスクわかってるのか？
1.よくわからないやつ
手を出さないで素直にLinuxを勉強する。
IS01RooterとSDKでコマンドプロンプトからadbで色々遊べる。
2.Swap有効化したい、Adhoc有効化したい
Swapやadhocのファイル書き換え程度なら文鎮化するリスクなどほぼ無いので、
Recovery領域にnvさんか仙石さんのカーネルイメージを書き込む。
これなら書き損じても通常Bootでき、文鎮化は回避できる。
又、書き損じて文鎮化するリスクを覚悟出来るなら、
Recoveryをオリジナル、Bootを改造カーネルする。
これなら、わざわざRecoveryから起動する必要がなく、工場出荷状態に戻すが使えるようになる（らしい）
3.adhocやswap以外にSystemをいじりたい(build.porpなど)
起動時に影響するシステムファイルを書き換えるなら、
Recovery_kitを導入したほうが起動時にこけた場合に復旧が可能となるので入れたほうがよさげ。
ただし、Bootを書き換えるので書き損じると文鎮化するリスクあり。
こんな感じか？
だいたいの奴は２だろ？
Recoveryにカーネル書き込むぐらいで平気だろ。
918
自分で試してみました。やはり、qxdm_enableによってadbdの認識状況が変わるようです。
0だと、放置しても認識しません。
1にすると、ちょっと放置すると認識しました。
qxdm_enableが0でも、recovery領域に通常起動用のカーネルを焼いておくことで、1に設定するために
リカバリメニューから通常起動用のカーネルを起動させることが可能です。
また、qxdm_enableを1にするための方法を、次回アップデート時に追加します。
まとめとして、recovery_kitを使用するときは、qxdm_enableを1に設定し、recovery領域に通常起動用のカーネルを
焼いた上で使用してください。
926
>>918
いろいろ進んでいるみたいでよかったです。bootloader入れることもいろいろ検討しましたが、
・fastbootのubi対応が面倒くさい(標準では実装がない）
・初回インストール時に結局文鎮化の恐れ自体は存在する（NANDを書き換える点では変わらない）
というわけで、NVさんの解法標準領域をRecovery用にしておいて、本来のRecovery領域で再起動する、
が一番スマートかなと思いました。
ちなみに、qxdm_enableに1を書いておくと、adbが有効になる理由は、カーネルソースコードの
drivers/usb/function/msm_hsusb.cの4055付近でqxdm_enableだったら、adb_enableにする、っていう
実装が入っていることにより行われます。
echo adb=1 > /sys/devices/platform/msm_hsusb_periphera/func_enable
でも同様の効果が得られます。
927
recovery_kit v1.30をリリースしました。
qxdm_enableを1にするための項目をリカバリメニューに追加しました。
導入している場合は"必ず"更新をお願いします。
http://www.megaupload.com/?d=D3F66M78
928
>918
おおぉ…ということは
/recoveryがデフォルトでqxdm_enable=0の状態で入れてしまったら
文鎮(電池充電機能付き)決定ということですね
といいつつ懲りずに今日is01もう一つ買ってきました
931
>>928
v1.25まではそうでしたが、v1.30からqxdm_enableをリカバリメニューから1にできるようになったので、
文鎮化の可能性は低くなってます。
945
IS01のfirmware updateはイノパスソフトウェアのMobile Updateで実現してるらしいね。
http://www.innopath.com/jp/news/press_releases/2010/2010_06_23.shtml
SyncML、OMADMなどを参照すると良いかも。
948
>>945
ひえー。ゴロー君たちはこのバイナリを解析していることに
なるのか。本当に乙です。
342
現在の状況ですが、
モデム側のsharp版downloaderモードのパケット解析進行中です。
モデム側のfirmwareは参考ソースもなく、バイナリの量が多くて時間がかかりましたが・・
ダウンロードモードに移行後任意のバイナリをメモリ上に転送するところまで行きましたが、
実行するためには認証チェックがあるためそこをどうにかすることを検討中。
これ利用して、モデム側のfirmwareからfastboot起動することや
bootloaderそのものの書きかえもできるようになると思います。
246
>>244 fi01さん
そちらのディレクトリ構成のがわかりやすいですね。
私の方はちょっとごちゃごちゃしてます^^;
ふと、思いついたのですが、mount、permission設定 までを
init.rc に書き、以降の service 部分などはファイルシステムから
include すると boot.img を１回作成するだけで良いかもしれません。
確か、init に import が有ったような気がします。
ドキュメントちゃんと読んでないのでこれからですが、試してみます。
346
>>246
initのimportコマンドとmountのloop@～も一応動いたから
毎回flash_imageしなくても環境切り替えが可能に出来そうです。
execまで使えるように変更すれば、ほとんどブートローダになりそう。
最終更新：2010年12月28日 21:01
