2011年06月30日

光iフレームのファイルシステムを調べる(2)

さて、ディスクイメージを取ったものの、このファイルシステムはMacでは読めないjffs2です。

でもLinuxなら読めるんですよね、Linuxなら…。







細かいことは考えず、VMWareでLinuxをインストールすることにしました。
Android自体、Linuxがプラットホームですからね。カーネルをいじるにはやはりMacよりLinuxでしょう。

さて、通常ディスクイメージはloopbackデバイス経由でマウントできるのですが、jffs2は少し状況が違うようです。

jffs2イメージをloopback mount - Pylone Blog

上のリンクにあるように、いったんblock2mtdドライバを介さなければならないそうです。
最初、普通にマウントしようとしてうまくいかず、悩んでしまいました。
やはり、何かおかしいときにはgoogle先生にお伺いを立てるほうがいいですね。

方法さえ把握してしまえば

# losetup /dev/loop0 mtd6.bin
# modprobe block2mtd block2mtd=/dev/loop0
# mount -t jffs2 -o ro /dev/mtdblock0 test

こんな感じで、無事マウントして中身をのぞくことができました。

ちなみにmtd6とmtd7は、やはりファームウェア新旧のルートファイルシステムのようです。
全ファイルのリストを取って調べてみましたが、差分は比較的小さなものでした。


mtd0〜mtd5は、ディスクイメージではないようです。
調べてみたら、こんな感じでした。

■mtd0(boot1)、mtd1(boot2) … たぶんブートローダ

stringsで中の文字列を表示させてみると、ブートローダのようです。
boot1とboot2は別モノで、boot1の中でboot2の内容をチェックしているらしい。
boot1がモニタでboot2がLinuxローダとか、そんな感じに見えます。


■mtd2(ctrl) … 何らかの制御用データ、起動パラメータ?

中はファイル名らしきものと、日付が入っています。こんな感じ。

sh-3.2$ strings mtd2.bin
Thu Mar 10 15:31:21 2011
ota_WDPF_701ME_ES2_FACTORY_NS_timbit_v2.1.1-MP4_jffs2.bin
H78Thu Dec 16 09:28:03 2010
ota_WDPF_701ME_ES2_FACTORY_NS_timbit_v2.1.1-MP4_jffs2.bin
Thu Mar 10 15:31:21 2011
ota_WDPF_701ME_ES2_FACTORY_NS_timbit_v2.1.1-MP4_jffs2.bin
H78Thu Dec 16 09:28:03 2010
ota_WDPF_701ME_ES2_FACTORY_NS_timbit_v2.1.1-MP4_jffs2.bin
sh-3.2$


■mtd3(nvdata) … /nvdataにマウント(jffs2)

設定情報を保持しているようですね。中身はこんな感じです。
$ cd /nvdata
$ ls
etc voip
$ cd etc
$ ls -lat
drwxrwxrwx 3 root root 0 Jun 29 12:25 .
-rw------- 1 10015 10015 109 Jun 29 12:25 update_check_result
-rw------- 1 10015 10015 91 Jun 29 09:45 update_check_fail
-rwxrwxrwx 1 root root 18 Jun 29 09:14 mac_address
-rw------- 1 10015 10015 0 Jun 8 17:31 froyo_updated
-rw-r--r-- 1 root root 638 Jun 8 17:30 wl-nvram.txt.temp
-rwxrwxrwx 1 1000 1000 11 Jun 8 17:28 update_date
drwxrwxrwx 5 root root 0 Mar 29 17:46 ..
-rw-r--r-- 1 root root 18 Mar 29 17:45 mac_address2
-rwxr-xr-x 1 root root 12 Mar 29 17:45 product_id.back
-rwxrwxrwx 1 root root 12 Mar 29 17:45 product_id
-rwxrwxrwx 1 root root 6 Mar 29 17:45 firmware_version
-rwxr-xr-x 1 root root 4546 Jan 1 1970 network-interface.cfg
-rwxr-xr-x 1 root root 653348 Jan 1 1970 vmcs_all.bin
-rwxr-xr-x 1 root root 0 Jan 1 1970 LMS700KF23
-rwxr-xr-x 1 root root 5931 Jan 1 1970 vcboot_LMS700KF23
-rwxr-xr-x 1 root root 193643 Jan 1 1970 vceb.bin
-rw-r--r-- 1 root root 210 Jan 1 1970 enet.cfg
drwxr-xr-x 2 root root 0 Jan 1 1970 greybox
$ mount|grep mtd
/dev/mtdblock3 on /nvdata type jffs2 (rw)
/dev/mtdblock10 on /firmwarestorage type yaffs (rw)
$


froyo_updatedっていうファイルがあるのがちょっと気になりますねー。
froyoというのはAndroid2.2ですからね。
やはり2.2へのアップグレードが計画されているのでしょうか。


■mtd4(k0)、mtd5(k1) … Linuxカーネル

ARMのzImageのマジックナンバー(016f2818)が入っていますので、zImageで間違いないでしょう。

sh-3.2$ od -x -A x -v mtd4.bin |head -4
0000000 0000 e1a0 0000 e1a0 0000 e1a0 0000 e1a0
0000010 0000 e1a0 0000 e1a0 0000 e1a0 0000 e1a0
0000020 0002 ea00 2818 016f 0000 0e00 b0b8 0e21
0000030 7001 e1a0 8002 e1a0 2000 e10f 0003 e312
sh-3.2$ od -x -A x -v mtd5.bin |head -4
0000000 0000 e1a0 0000 e1a0 0000 e1a0 0000 e1a0
0000010 0000 e1a0 0000 e1a0 0000 e1a0 0000 e1a0
0000020 0002 ea00 2818 016f 0000 0e00 b028 0e21
0000030 7001 e1a0 8002 e1a0 2000 e10f 0003 e312
sh-3.2$


参考:
Booting ARM Linux


■mtd6, mtd7は前回見たようにルートファイルシステムですね。

■mtd8〜mtd10 … 特定のマウントポイントにマウントするファイルシステム

dmesgから

mtd8(userdata) … /data (UBIFS)
mtd9(dpfdata) … /dpfdata(UBIFS)
mtd10(firmwarestorage) … /firmwarestorage (yaffs)

と分かります。

UBIFSもjffsと同じくフラッシュ向けのファイルシステムで、大容量フラッシュのマウントにはjffsよりも向いているそうです。

参考:
CEREVO TechBlog - Introduction of UBIFS


■mtd11〜mtd13

内容を推測すると、多分

mtd11(factoryreset) … mtd10と同じサイズなので、初期化に使う?
mtd12(serialdata) … 0.5MB。0xFFで埋められている。使っているのかどうかも不明。
mtd13(vcfw) … 2MB。ビデオ処理用プロセッサのファームウェア?

という感じだと思います。
今のところ、ちょっと興味がわかないので、この3つは放置で…。
posted by boochow at 01:29| Comment(0) | Android | このブログの読者になる | 更新情報をチェックする

2011年06月27日

光iフレームのファイルシステムを調べる(1)

Linuxのソース探検の次は、光iフレームのファイルシステムを調べてみます。
まだ途中ですが…。

基本的な情報はコンソールに出てくるメッセージで確認できます。
通常、このメッセージはdmesgコマンドで確認できますが、光iフレームではroot権限が必要です。
adb bugreportで得られるレポートでも一部情報は得られますが、root権限があるほうが何かと便利なので、ここは素直に(?)取りに行きます。

もちろん、これはOSの脆弱性を攻撃してroot権限を取るという行為なので、以後何が起きても自己責任です。念のため。

やり方は、いつものこちらにも記載されている通りです。

(-_-): WDPF-701ME


rageagainstthecage-arm5.binを実行したら、私の場合は一発でroot権限が取れました。

SuperUser.apkをインストールしておくと、suすると端末の画面上に許可を求めるメッセージが出るようになります。

これで、Linux起動時のシーケンスはもちろん、ファイルシステムのそこかしこが覗き放題になりました。

…が、これって結構危険な状況ではあるんですよね。
遅かれ早かれ、何かしくじってシステムを壊してしまうことになる気がします。
スーパーユーザー権限は不必要に使うものではないです。


そこで、今後に備えて、2つほど安全策を考えてみました。

1つは、光iフレームのファイルシステムのバックアップを取ること。
光iフレームに毎回shellで接続するのではなく、ファイルシステムのコピーをMac側へ持ってきてしまえば、少なくとも中身の調査はMac側だけで行えます。

持ってくるには、adb pullするという強引な手もなくはないですが、それよりもディスクイメージを作成し、Mac側でイメージファイルをマウントするほうがスマートです。

もう1つは、コンソールとしておそらくシリアルポートが使われているはずなので、光iフレームの基板上からシリアルポート信号を引っ張りだすことです。

これができれば、adbの助けを借りずとも、コンソールから直接shellへ入れるようになります。


さて、まず1つ目のディスクイメージですが…
光iフレームはフラッシュメモリ上にファイルシステムを作っています。
ディスクに相当するデバイスは、/dev/mtd**になるようです。

ただ、ファイルシステムは通常のLinuxのようなext3などとは違います。
dmesgを見ると、
kernel: VFS: Mounted root (jffs2 filesystem) on device 31:6.

というログがありましたので、jffs2ですね。
これはフラッシュメモリをターゲットに設計されたファイルシステムです。

ところで、光iフレームはルートファイルシステムを2つ持っているようです。
kernel: 0x000000000000-0x000000080000 : "boot1"
kernel: 0x000000080000-0x000000100000 : "boot2"
kernel: 0x000000100000-0x000000200000 : "ctrl"
kernel: 0x000000200000-0x000001200000 : "nvdata"
kernel: 0x000001200000-0x000001500000 : "k0"
kernel: 0x000001500000-0x000001800000 : "k1"
kernel: 0x000001a00000-0x000009800000 : "root0"
kernel: 0x000009800000-0x000011880000 : "root1"
kernel: 0x000011880000-0x000038e80000 : "userdata"
kernel: 0x000038e80000-0x000058e80000 : "dpfdata"
kernel: 0x000058e80000-0x000060e80000 : "firmwarestorage"
kernel: 0x000060e80000-0x000068e80000 : "factoryreset"
kernel: 0x000068e80000-0x000068f00000 : "serialdata"
kernel: 0x000001800000-0x000001a00000 : "vcfw"

こんな感じになっているので、boot1とboot2、k0とk1、root0とroot1があります。
ファームウェアの更新のために、起動に必要なファイルシステムは2つずつ持っているのかもしれません。

さて、とりあえずルートファイルシステムはroot0ないしroot1ですから、boot1が/dev/mtd0とすると、/dev/mtd6と/dev/mtd7がroot0、root1に相当すると思われます。

このディスクのイメージを取るには

dd if=/dev/mtd6 of=/sdcard/mtd6.bin

こんな感じでSDカード上に保存します。

このファイルをMac上に持ってきて、調べたいわけですが、残念ながらMacはjffs2を読めないんですね…。

というわけで続きます。
posted by boochow at 01:41| Comment(0) | Android | このブログの読者になる | 更新情報をチェックする

2011年06月20日

WDPF-701MEのソースコードを眺める

光iフレームのソフトウェアのうち、オープンソースを利用しているものはソースコードがNTT-MEからダウンロードできます。


弊社製光iフレーム WDPF-701ME をご購入のお客様へ


これをダウンロードして、中身を覗いてみました。

予想通り、中身はAndroidとLinuxカーネルです。
Androidはよく分かりませんが、Linuxは昔それなりに使い込んでいたので、ちょっと見てみました。

カーネルは2.6.29ですが、ファイルの更新日付を見てみると、2010年10月21日付けのものと、2009年のものがあります。
新しいファイルは、おそらくBroadcomが自社プラットホーム向けに手を加えたものだと思われます。

find . -mtime -250d | wc

してみると、1600ほどのファイルが更新されていました。


更新されたファイル群を、ざっとディレクトリ名だけ眺めてみます。

find . -mtime -250d -type d | more

すると、大幅な更新が目立つのは
./arch/arm/mach-bcmring
./drivers/char/broadcom
./vmcsx

というあたりです。
archの下のソースは個別のハードウェアプラットホームに依存する内容ですから、bcmringというのは光iフレームそのもの、ないしはその開発ボードの名称かもしれません。

そう思って先日の、adb bugreport で取ったログをgrepしてみると、
26 26 0% D 0K 0K fg root bcmring_ddrvpmp[ro.hardware]: [bcmring_custom]
<4>bcmring_pm_init: Initializing Power Management for BCMRING....
<6>bcmring-rtc0 bcmring-rtc0: rtc core: registered bcmring as rtc0
<6>bcmring-rtc0 bcmring-rtc0: setting system clock to 2011-06-12 10:01:52 UTC (1307872912)
<4>bcmring_net configuration: brcmMode=0, descRx=64, descTx=1024
root 26 2 0 0 fg c0059800 00000000 D bcmring_ddrvpmp
root 26 2 0 0 20 0 0 0 fg c0059800 00000000 D bcmring_ddrvpmp

という具合にひっかかってきました。
どうやら光iフレームのハードウェア依存の情報は、mach-bcmringの下のコードを見れば見つかりそうですね。

先日気になっていた、Linux起動時の
bcm11xx_wait_sesdone: no ack

というメッセージも、出所がわかりました。
sh-3.2$ find . -mtime -250d|grep bcm11xx
./i2c/busses/i2c-bcm11xx-hw.c
sh-3.2$ grep wait_sesdone ./i2c/busses/i2c-bcm11xx-hw.c
static int bcm11xx_wait_sesdone( int clear_cmd )
if ( bcm11xx_wait_sesdone(1) < 0)
if ( bcm11xx_wait_sesdone(1) < 0)
if ( bcm11xx_wait_sesdone(1) < 0)
if ( (ack = bcm11xx_wait_sesdone(0)) < 0)
if ( bcm11xx_wait_sesdone(1) < 0)
sh-3.2$

ソースコードを見てみると、
static int bcm11xx_wait_sesdone( int clear_cmd )
{
(略)
ret = bcm11xx_wait_interrupt();
(略)
/* Get status from interrupt status register */
isr = ret;
(略)
if( isr & REG_I2C_ISR_NOACK )
{
I2C_DEBUG(DBG_ERROR, "no ack\n");
i2c_errors++;
}

と、こんな流れになっています。

タイムアウトするとタイムアウトのエラーメッセージが出るようですが、ログにはそのエラーは出現していません。
なので、i2cで接続されているデバイスの何かが、反応が遅いだけなのかもしれません。

まあ、i2cで何が繋がっているのかが分からないので、これ以上は分かりませんが…
posted by boochow at 00:03| Comment(0) | Android | このブログの読者になる | 更新情報をチェックする

2011年06月17日

光iフレームを普通のAndroidタブレットに

これまでiPod TouchやiPadしか使っていなかったので、Androidの端末は勝手が違うこともいろいろあります。

「ウイジェット」と「ホームアプリ」もそういうものの一つです。


光iフレームのスライドショーの画面に、時計やカレンダーのウイジェットを表示させて、ウイジェットは、まあ何となく雰囲気は分かりました。

ちなみにカレンダーはこちらを使わせて頂きました。

side2.jp ≫ Calendar Widget



ホームアプリは、感じとしてはビジュアルシェルということなのでしょうかね。

ネットをさまよっていたら、このページを見つけて、真似させていただきました。

家モバイラーの戯言 : 光iフレームに野良アプリをインストール その2


ここに書かれているLauncherProを普通にadbでインストールしたら、いつもと違ってアプリ一覧に出てきません。

再起動したら、ホームアプリを選択する画面が出てきました。

そこでLauncherProを選択。

なんと、光iフレームが普通のAndroidタブレットになりました…。

まあ最初からそういう使い方をしたいと思っていたので、願ったりかなったりですが。

動きも、標準のスライドショーアプリよりも軽快です。


あと、上記のページにはSimejiの設定方法も書かれていたので、これも実行しました。

実は前回Simejiをインストールしたものの、どうやれば入力がSimejiに切り替わるのか分からず、アンインストールしてしまっていました。

テキスト入力フィールドで長押しすれば選択ダイアログが出てくるのですね…。


何日か経って、慣れてきたせいか、この光iフレームもそこそこ使い物になる気がしてきました。

K-9 Mailでメールマガジンを見て、リンクされているページはDolphin Browserで閲覧。

一休みするときにTwidroydでツイッターを眺めたり、Tuboroidonで2ちゃんねるを眺めたり。

ビューワー中心の使い方なら、iPadには劣るけどiPod Touchより画面が大きいだけ有利かなと思わないでもありません。

これでもう少しバッテリーがましだったら、コミックビューワで電子書籍端末代わりにもなりそうだったのですが…。

ちなみにコミックビューワはACV(Droid Comic Viewer)が割といい感じでした。
posted by boochow at 23:23| Comment(0) | Android | このブログの読者になる | 更新情報をチェックする

2011年06月16日

野良アプリで光iフレームを活用?する

USB経由でのアプリインストールが可能になったので、いろんなソフトを光iフレームにインストールして、動作を試してみました。

Androidのバージョンが古いためにインストールできないもの、インストールはできたけど正常に動かないものもありますが、まあ6割か7割は動くような感触です。


最初、アンインストールの仕方が分からなくて困惑しました。
インストールのときは

adb install file_name

ですが、アンインストールのときは

adb uninstall package_name

なのですね。


パッケージ名はファイルの中に含まれるAndroidManifest.xmlに記載されているそうです。

アプリのファイル(apkファイル)は単なるzipアーカイブなので(このへんはJavaの流儀ですね)、unzipして読み出せないこともなさそうですが、Android SDKのコマンドを使うほうが簡単です。

aapt l -a file.apk |grep name=

これでパッケージ名を抽出できます。
こんな感じですね。

bash-3.2$ aapt l -a YouTube_signed.apk |grep name=
Package Group 0 id=127 packageCount=1 name=com.google.android.youtube
Package 0 id=127 name=com.google.android.youtube typeCount=11
bash-3.2$

"com.google.android.youtube" がパッケージ名です。
アンインストールは

adb uninstall com.google.android.youtube

という具合。


NTTの光回線に加入していれば、こんな苦労は不要なのでしょうが、私の環境では他に手段が無いので仕方ないですね。

実際にインストールしてみて、良さそうだと思ったものを挙げてみます。
動作したバージョンが分かるようにファイル名も書いておきます。


●やっぱりこれがないと…
K-9 Mail(K-9_Mail_3.801.apk) 電子メールクライアント
Dolphin Browser HD(Dolphin_Browser_HD_5.0.1.apk) Webブラウザ

●ネットのご利益を感じるには、これ
Google Maps(Google_Maps_4.7.0.apk) 地図ソフト
Tuboroidon(Tuboroidon_0.1.2.apk) 2ちゃんねるリーダー
TuneIn Player(tunein.player-1.apk) ネットラジオ
Twidroyd(Twidroyd.apk) ツイッター

●ユーティリティなど
Advanced Task Killer(Advanced_Task_Killer_1.9.6B76.apk) アプリを終了させるのに便利
ASTRO File Manager(ASTRO_File_Manager_2.5.2.apk) ファイル管理、いわゆるビジュアルシェル
Adobe Reader(Adobe_Reader_9.0.2.apk) 純正PDFリーダー


メールは、タッチパネルで入力する気にはなれませんが、読むだけなら十分使い物になります。
メール中のリンクをクリックするとブラウザに飛べますし、この連携のスピード「だけ」はiPhone/iPadより快適な気がします。

Google Mapsは、iPadほどではないものの、思ったより使い物になりそうでした。

また、Adobe Readerも日本語も表示できるし、そこそこ使えます。
電子ブックの代わりに、できなくはないかもしれないと思わないでもないですね(歯切れが悪い)。
ただ、Reader単体では使えないので、ASTRO File ManagerからSDカードのファイルを選んで、Adobe Readerを起動するようにします。

RAMが256MBしかないので、不要なアプリはこまめに終了させたほうが良さそうです。
Advanced Task Killerは通知領域に常駐してくれるので便利です。
posted by boochow at 21:57| Comment(0) | Android | このブログの読者になる | 更新情報をチェックする
人気記事