ブートローダー

「ブートローダー」の編集履歴（バックアップ）一覧はこちら

「ブートローダー」(2010/12/28 (火) 21:01:03) の最新版変更点

追加された行は緑色になります。

削除された行は赤色になります。

>>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にできるようになったので、 
>  文鎮化の可能性は低くなってます。 

>>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まで使えるように変更すれば、ほとんどブートローダになりそう。