2012年05月13日

光iフレーム(WDPF-701ME)の基板を見てみた

一年近く経ってしまいましたが、前回の記事にコメントを頂いていて、光iフレームの筐体のネジは4箇所だけで、あとは力任せに開けられる、シリアルポートも配線されている、ということでしたので、試しに開けてみました。
もはや置物と化していて、失敗しても惜しい感じはしませんし…。

結果、ネジを外した後は隙間にマイナスドライバをねじ込んで、バキバキと開けることができました。
中身はこんな感じです。

wpdf-701me-board1.jpg
(クリックで拡大)

Broadcomのチップが2つあり、大きいほうがBCM11211、小さいほうがBCM11181、その隣はhynixのH27UAG8T2ATR-BC(16Gb NAND Flash)です。
中央に2つあるのはK4T1G084QFとあり、1Gb DDR2 SDRAMです。
2つなので256MB分ですね。

さて、左下のほうのTTA-20コネクタ周りですが、こんな感じになっています。

wpdf-701me-board2.jpg

上側が1番ピン、下側が20番ピンとなっているはずです。
ピンアサインは以下のドキュメントに出ています。

e0bb0adf ac47 c397 5dc7 49d5f1c17155 ppt


Found at ebookbrowse.com


シリアルポートはRxDが15番、TxDが16番ですが、基板の状況を見る限りでは、15番はGNDに落ちていて16番は信号が来ているようです。
従って、コンソール出力はここに出ている可能性がありますが、コンソールへ入力することはできないかもしれませんね。
17〜19番ピンはUSBですので配線されていますが、1〜14番ピンは使われていない可能性が高そうです。
posted by boochow at 12:56| Comment(0) | Android | このブログの読者になる | 更新情報をチェックする

2011年07月03日

光iフレームのシリアルポートへの道は遠い…

前回、一応ファイルシステムの中身を見るメドは立ちました。もう一つの課題は、実際に中身をいじる場合に備えたシリアルポートへの接続ですが…結論から言うとまだ入り口にもたどりつけていません。

dmesgを見ると

kernel: Kernel command line: console=ttyAMA0,115200n8
kernel: Serial: AMBA PL011 UART driver
kernel: UARTA: ttyAMA0 at MMIO 0x80012000 (irq = 46) is a AMBA/PL011
kernel: console [ttyAMA0] enabled
kernel: UARTB: ttyAMA1 at MMIO 0x80013000 (irq = 44) is a AMBA/PL011

とあるので、コンソールはttyAMA0に設定されています。
また、/init.rcには

service console /bin/sh
console

とあるので、コンソールでシェルが動いているはずです。

あとは、ttyAMA0に対応する物理的な端子に接続できれば、コンソールに到達できるのですが、それにはまず基板を見てみないと、実現の可能性も分かりません。

従って、何はさておき光iフレームのケースを開けて、基板を取り出さねばなりません。

しかし、これが意外と難関です。


光iフレームの両側面に、それぞれ2つずつネジ止めがあります。
これを外せば基板が見られるかな?と思い、専用のドライバーを買ってきました。

ちなみに専用のドライバとは、「イジリ止めヘックスローブ」に対応したものです。

光iフレームのネジは六角の星形で、しかも中央に突起(イジリ止め)があります。
対応するのは非常に特殊な工具なのかと思いましたが、近所のホームセンターで、8本のレンチのセットで、1000円もしませんでした。


しかし、残念ながらネジをはずしただけでは、びくともしません。

爪ではまっているだけかと思ったのですが、4つのネジ以外に、中央部分にもケースを固定している箇所がありそうです。
隠しネジかと思いましたが、見つけられませんでした。

無理に分解するには、最悪、元に戻せなくなっても仕方が無い、という覚悟が必要な感じです。

基板を見てるらしい人も、いるんですけどね…

WDPF-701MEの基盤 ≫ 日々是"精進"。


そんなわけで、さすがに破壊覚悟で開けてみる勇気はないので、いつか誰かが分解手順を見つけてくれるのを待つことにします。


他には、adbでの接続に使っているTTA-20コネクタも、規格上はシリアルポート信号のための端子があります。

工人舎PMのTTA20コネクタ

普通のシリアルポート信号ではなく、2.6±0.2Vですが、これはまあありがちなパターンです。
秋葉原の秋月電子あたりでレベルコンバータ用のICを調達してくれば、普通のシリアルポートへ接続できます。

しかし、光iフレームは開発ボードではなく製品なので、わざわざシリアルポートまで配線してないような気もします。

まあ、信号が来てるかどうか調べてみる価値はあるかもしれません。
ただ、このTTA-20のプラグがなかなか国内では入手できないんですよね…。

こちらの方みたいに、ACアダプタのケーブルをバラしてみるしかないんでしょうか…。
NTTのサポートに連絡すれば、ACアダプタの入手もできるのかなあ…。

WDPF-701MEの通信ケーブル自作 NTTからの脱獄 ≫ 日々是"精進"。

2ちゃんねる情報によると、そろそろAndroid 2.2へのアップデートがあるかも?
ということなので、中身をいじり回すのはしばらくおあずけのほうがいいかもしれませんね。
posted by boochow at 01:15| Comment(2) | Android | このブログの読者になる | 更新情報をチェックする

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 | このブログの読者になる | 更新情報をチェックする
人気記事