前回はboot.imgを作りましたので、実機で動かしてみましょう。
先ずはbootloaderに再起動します。
HTC製品の方はUSBケーブルを繋いで、ボリューム下を押しながら電源ON
もしくはadbで
bootloaderの赤反転文字が「FASTBOOT USB」となっているのを確認したら、
目的のboot.imgがあるカレントで
再起動がかかります。
今は先程のboot.imgが適用された状態だけどもnandに書き込まれていない
特殊な状態となっていて再起動すると元に戻ります。
boot.imgを弄ったは良いが腐っていて起動しない事はままあるので
こうやってテストすると手戻りが無くて良いですね。
一通りの動作が確認出来てOKだと思ったら、もう一度bootloaderから
これで書き込み完了です。
ここからは「俺の機種はfastbootなんて使えねぇよ！」という人向け。
上記の様なテストは出来ず、いきなり書き込む事になりますのでバックアップは取って置いて下さい。
・flash_imageを使う方法
RomManegerをインストするとflash_imageが付いて来ます。これを利用する方法。
boot.imgをsdcardに突っ込んで
tegraの機種を使っている人は同じディレクトリにある「tegra_flash_image」を使ってください。
ちなみに
とやるとリカバリーの書き換えが出来ます。
RomManegerのClockworkMod更新はこういった仕掛けになっています。
・ClockworkMod Recoveryを使う方法
/sdcard/clockworkmod/backupに適当な名前のディレクトリを作ってboot.imgを入れます。
adb shellで作ったディレクトリに移動して
後はClockworkMod Recoveryを起動しAdvanced Restoreからbootを書き込めば終了。
上記のmd5sumを使ってnandroid.md5を作る仕組みは
バックアップファイルの特定領域だけ挿げ替えるのにも応用できます。
先ずはbootloaderに再起動します。
HTC製品の方はUSBケーブルを繋いで、ボリューム下を押しながら電源ON
もしくはadbで
| adb reboot bootloader |
bootloaderの赤反転文字が「FASTBOOT USB」となっているのを確認したら、
目的のboot.imgがあるカレントで
| fastboot boot boot.img |
再起動がかかります。
今は先程のboot.imgが適用された状態だけどもnandに書き込まれていない
特殊な状態となっていて再起動すると元に戻ります。
boot.imgを弄ったは良いが腐っていて起動しない事はままあるので
こうやってテストすると手戻りが無くて良いですね。
一通りの動作が確認出来てOKだと思ったら、もう一度bootloaderから
| fastboot flash boot boot.img fastboot reboot |
これで書き込み完了です。
ここからは「俺の機種はfastbootなんて使えねぇよ！」という人向け。
上記の様なテストは出来ず、いきなり書き込む事になりますのでバックアップは取って置いて下さい。
・flash_imageを使う方法
RomManegerをインストするとflash_imageが付いて来ます。これを利用する方法。
boot.imgをsdcardに突っ込んで
| /data/data/com.koushikdutta.rommanager/files/flash_image boot /sdcard/boot.img |
tegraの機種を使っている人は同じディレクトリにある「tegra_flash_image」を使ってください。
ちなみに
| /data/data/com.koushikdutta.rommanager/files/flash_image recovery /sdcard/recovery.img |
とやるとリカバリーの書き換えが出来ます。
RomManegerのClockworkMod更新はこういった仕掛けになっています。
・ClockworkMod Recoveryを使う方法
/sdcard/clockworkmod/backupに適当な名前のディレクトリを作ってboot.imgを入れます。
adb shellで作ったディレクトリに移動して
| md5sum boot.img > nandroid.md5 |
後はClockworkMod Recoveryを起動しAdvanced Restoreからbootを書き込めば終了。
上記のmd5sumを使ってnandroid.md5を作る仕組みは
バックアップファイルの特定領域だけ挿げ替えるのにも応用できます。
![[Android] boot.imgを入れ換えたらwifiが繋がらなくなったんだけど](https://blogimg.goo.ne.jp/image/upload/f_auto,q_auto,t_image_square_m/v1/user_image/5d/6f/3def49dd04f52b052787fc8a7a403abb.jpg)
![[Android] boot.imgを展開してみる その2](https://blogimg.goo.ne.jp/image/upload/f_auto,q_auto,t_image_square_m/v1/user_image/3a/d4/082324e5a22576c367858c846051489f.jpg)
bootramdiskを改修したいと思いいろいろと参考にさせていただきました。
Android4.0の中華PADを使っているのですが、ここまでの、boot.imgを抜き出して修正し、固めるところまではできたのですが、最後の、改修したイメージを入れ込むところがうまく行きません。
というのも、adb reboot bootloader と実行しても、どうやらうまくbootloaderモードに入っていないようで、
fastboot boot new_boot.img
と実行しても、fastbootコマンドが戻ってこない状態です。
起動時に、オリジナルのスプラッシュが面が表示される端末で
＞ bootloaderの赤反転文字が「FASTBOOT USB」となっているのを確認したら、
という部分が確認できないのですが、adb reboot bootloader を実行してもブートローダーモードに入らない場合の対処法はどのようなものがあるでしょうか。
よろしくお願いします。
記事中のflash_imageを使う方法やClockworkMod Recoveryを使う方法
を試してみてください。
もしboot.imgをddで取得したのであれば
dd if=[boot.imgのフルパス] of=[boot bolckのデバイス名]
で行けるかも知れませんがこれは実際試していないので、
書き込みパーミッションが無いと怒られるかもしれません。
なるほど、Android端末でも対応している機種とそうでない機種があるのですね。
そうしますと、追加でもう１点、教えていただければうれしいのですが、これの前の記事で書かれていたrepack-bootimg.pl内のsystemコマンドのことなのですが、
system ("mkbootimg --cmdline 'boot_img_hdr.exeで取得したcmdlineの内容' --base boot_img_hdr.exeで取得したtags_addrの内容 --kernel $ARGV[0] --ramdisk ramdisk-repack.cpio.gz -o $ARGV[2]");
私の環境ではこれらの数字を得るために実行したboot_img_hdr.exeの実行結果が
$ ./boot_img_hdr.exe boot.img
kernel_size : 4119240
kernel_addr : 0x10008000
ramdisk_size : 1273224
ramdisk_addr : 0x11000000
second_size : 0
second_addr : 0x10f00000
tags_addr : 0x10000100
page_size : 2048
unused : 0x28a8c4
name :
cmdline :
このようになり、cmdlineに何も表示がされませんでした。
そこで、/proc/cmdlineを見て見ると
$ adb shell cat /proc/cmdline
mem=448M root=/dev/ram0 rw initrd=0x01400000,0x136d88 ubi.mtd=13 console=ttyS0,115200n8 init=/init
となっていました。
上記２つの結果を組み合わせてrepack-bootimg.plの中身を
system ("/home/tablet/mkbootimg --cmdline 'console=ttyS0,115200n8 init=/init no_console_suspend=1' --base 0x10000100 --kernel $ARGV[0] --ramdisk ramdisk-repack.cpio.gz -o $ARGV[2]");
としてみたのですが、これで大丈夫でしょうか。
自分では、115200n8と、init=/initが必要なのか不要なのかが判断できず…
fastbootが使えれば、実際の書き込みをせずに試せるとのことでしたので、試しながら動く状態を探して行けば良いと考えていたのですが、実際の書き込みをしなければ試せなさそうとなると、失敗できないので…
質問ばかりで申し訳ありませんが、よろしくお願いします。
一発勝負は怖いのでちょっとだけ確認させてください。
・ClockworkMod Recoveryが使える機種でしょうか？
・電源OFFから直でRecoveryに入れる特殊キー操作等がありますか？
・adb reboot bootloaderを実行した時に画面上には何か表示されていましたか？真っ黒でしたか？
差し支えなければ機種名を教えて頂けると話が早いです。
> Clockwork Mod Recovery
これにつきましては、導入はしてみたのですが、実は使い方が良くわかっておらず、あまり触っていませんでした。
とりあえず、現状としてはClockworkModのROM Managerはインストールできており起動するのですが、「現在のROMをバックアップ」や「リカバリへ再起動」などを実行してみても、見た目上動いている様子はありません。
boot.imgが書き換えられれば先に進める予定でしたのでそれが終わってからもう少し調べてみようと思っていて、まだ深く確認していない状況です。
> 電源OFFからRecoveryに入れる特殊キー
こちらは、マニュアルにも記載がないためはっきりとわからないのですが、おそらく、ないだろうと思っています。
ハードウェアキーとしては、電源、ボリューム、リセットの３種類のみで、電源起動時にボリュームキーを抑えながら起動させると左下に「セーフモード」の文字が表示された状態で起動します。
adbからreboot recoveryと実行したこともあるのですが、スプラッシュ（？）のような、Androidのロボットの中をいじってる様子の画像が表示されるだけで特段操作ができず、adbも受け付けてくれない状態だったため、こちらについてもいったん調査を保留している状態です。
> adb reboot bootloaderを実行した際の画面
こちらについては、通常の電源投入時と同じ画面が表示されていて、Androidのロボットを使った起動画面が表示されています。
また、右下にはAndroid、Kernel、Buildの各バージョン番号が表示されています。
この辺は自分のブログでレビュー記事にしましたので、こちらをごらんいただければ実際の画面もご確認いただけます。
http://taedoo.at.webry.info/201209/article_2.html
（起動画面は真ん中くらいに画像が張ってあり、bootloaderで起動した際もまったく同じ画面が表示されています）
機種は、レビューにも書いていますが、EKEN の W70 です。
http://www.eken.com/w70/
ただ、実は海外の通販サイトで購入する際に、当初同じメーカーのD70を注文したのですが、「テストしたら問題が出たから送れない。似たよな機種でW70があるからどうだ」といわれて、変更して手に入れた機種の上、ブログ冒頭にも書いたような、公式のリリースとはだいぶ具合が違う形で手元に届いているため、W70で間違いないとは自信を持って言えるような状態ではなかったりします…。
（端末自体にも刻印はありませんので）
追加情報として記入しておきますと、ClockworkMod RomManager上で、「ClockworkMod Revoceryを導入」を実行すると、表示される端末の種類としての記載は「WM8850-mid」となっています。
（これを実行した際には、英字で、official support対象外の端末だけど、手動でClockworkModをインストールしますかと聞かれます）
以上、お手数を煩わせてしまい申し訳ありませんが、よろしくお願いします。
ClockworkMod Recovryは機種毎に作成する必要があり、現段階でW70用の物は存在しません。
RomManagerはhttp://gh-pages.clockworkmod.com/ROMManagerManifest/devices.jsのスクリプトから
サポート対象の機種や導入方法を取得していますので
ここに記載が無いということは導入が行われていない事になります。
EKENからROMの提供も行われていない様ですし、BackUPも取れないとなると
復旧が難しいのでbootの書き換えは行わない方が良いと思います。
adb reboot recoveryで起動したのは恐らくW70純正のリカバリーです
キー操作若しくは、このモードに入れるある一定の法則が解れば多少進展すると思うのですが…
（例えば echo 1 > /data/.recovery_mode実行後に再起動するとか）
いろいろとお調べいただきありがとうございます。
ただ、実は業務の関係上、どうしてもbootの改修が必要でして…
というか、厳密には、bootが改修出来ればやりたいことができるはず、という期待を持って作業をしているのですが、本当にできるか否かはまだわかっておらず手探り状態で作業を進めておりました。
やりたいことと言うのが、以前、別の場所でも質問をしたことがあるのですが、USB機器を刺した時の、パーミッションを変更したいと言うものなのです。
これが実現できれば、別にbootを書きかえる必要はないのですが、今のところ、手立てが見つからず、boot領域に格納されている /ueventd.rc ファイル内に似たようなファイルのパーミッションを指定する記載があったことから、対象ファイルについて記述を増やせばできるだろうか、と期待してテストしたいと考えておりました。
（当該ファイル内に
/dev/ttyACM10 0666 radio radio
などの記載が多数並んでいることから、対象機器を認識する際のファイル /dev/ttyACM0 についても同様に書き込めばできるのではないかと考えました。ちなみに現状、ttyACM0の機器は0600のパーミッションで認識されるのですが、この機器を、Android端末上で実行するアプリから操作したいと考えており、パーミッションを0666で認識するようにしたいと考えてます）
もし、何かほかの方法でパーミッションの変更ができるのであれば、bootを改修する必要がなくなるのですが、何か試してみるとよい方法など思いつくことがありますでしょうか。
とりあえずは、すぐにbootを書き変えるのはいったん保留して、EKENの公式サイトで提供されている、W70ではない別の機種のファームの中身を解析して見ようと思います。
空っぽのSDカードに解凍したファームのデータを突っ込んで、電源を切った端末に差し込んで起動すれば更新できる、というもののようですので。
何かヒントが見つかりましたらまたご相談にあがるかもしれませんが、そのときはまたアドバイスなどいただければ助かります。
いろいろとお手数おかけしました。ありがとうございました。
念のため、最後に書かれていたコマンド（echo 1 > /data/.recovery_mode実行後に再起動）も試してみたのですが、普通に再起動してしまいました…。
ほかの機種の更新用ファームウェアをDLして見たのですが、ファイルサイズがおよそ200MB以上と、bootだけなくsystemまで入った形の物と思われるimgファイルが出てきただけで、解凍もできず手詰まりとなってしまいました。
もう２，３日いろいろ調べてみて、何もわからなければ、自己責任で作成したboot.imgを突っ込んでみようと思っていますが、その前に最後に確認をさせていただけないでしょうか。
今回、私はddを使ってbootパーティションのイメージを抜き出したのですが、ただぬきだしただけの手を加えていないboot.imgは、容量が約16MBあります。
このimgを解凍後、設定ファイルに１行追加の設定を書き込み、boot.imgを再構成したところ、新しくできたimgは約7MB程度となっています。
バイナリエディタで中身を確認すると、どうやら先頭130KBほどと、後ろ半分程度（約９MB）が0x00および0xffで埋められているようなのですが、両ファイルにおけるこの状態は、正しいものなのでしょうか。
また、当初質問させていただきましたcmdlineの引数となるコマンドの部分ですが、元のファイル内をANDROIDの文字で検索をかけると、作りなおしたファイルで、引数として指定したconsole…が記述されている部分は、すべて0x00でした。
この場合、やはりcmdlineは無指定にして、boot.imgを作り直したほうが良いでしょうか。
重ね重ね、質問ばかりで申し訳ありませんが、よろしくお願いいたします。
業務で使用しているのであれば壊してしまっても多少は金銭的なバックアップがありそうですね。
ファイルサイズの件ですが、ddで抜き出す物は対象パーテーションのダンプなので
パーテーションのサイズになります。
再作成後は実ファイルのみになるので減少するのは正常です。
あと、コマンドラインが入っていても特段悪さはしないと思いますが
出来れば無しにした方がよいです。
bootに書き込む前に多少のリスクは伴いますが以下を試してみて下さい。
先ずはinit.rcあれば/etc/fstab辺りからrecovery領域のデバイス名を調べてください。
そして
dd if=[調べたrecovery領域のデバイス名] of=/sdcard/recovery.img
で今入っているrecoveryのバックアップを取ります。
もし、recovery領域のデバイス名が分からない場合は
/dev/blockから適当に当たりを付けてddでダンプしてみて
unpack-bootimg.plで展開出来る領域を探します。
（recovery.imgは内容は違えどboot.imgとほぼ同じ構成です）
次に作成したboot.imgをsdcardに入れ
dd if=/sdcard/boot.img of=[調べたrecovery領域のデバイス名]
でrecovery領域にboot.imgを書き込みます。
これで通常起動時は元のboot.img、adb reboot recoveryを実行したら
改造したboot.imgから立ち上がる様になります。
動確が取れたらrecovery領域にrecovery.imgを書き戻し
boot領域に改造したboot.imgを書き込めばOKです。
なるほど。通常にbootしたときであれば、リカバリ領域から起動ができることを利用して、まずはリカバリ領域でテストをするということですね。
bootと比較するため、recoveryのほうもddで抜き出していたので、コマンドラインを消したboot.imgを作りなおしてこの方法でトライしてみます。
テスト結果はまた後ほどご報告させていただきます。