FT701Wでomap4bootに成功!

色々と問題はありますが、FT701Wで本体内蔵のファームを書き換えることなく、USBからカーネルを送り込んで起動することに成功しました!

ファームを解析して omap4boot に FT701W の初期化コードを追加してみました。

修正した omap4boot は github で公開してます。

ビルド方法は codesourcery の toolchain を使うので、今回は詳細は割愛しますが以下のような感じです。いろいろ整理ができたら詳しく書きます。

$ make TOOLCHAIN=??????/arm-2011.03/bin/arm-none-eabi- BOARD=ft701w

まだ実用じゃないですが、とりあえず使い方を。

  1. FT701Wのファームを展開し boot.img を取り出す
  2. FT701W の電源を落とす
  3. Linux PC 上で以下のコマンドを実行
    $ usbboot boot.img
    using built-in 2ndstage.bin
    waiting for OMAP44xx device...

    これで接続待ち状態になる

  4. FT701W と Linux PC をUSBで接続する。Linux PC で以下のような表示になれば成功
    reading ASIC ID
    CHIP: 4430
    IDEN: 0000000000000000000000000000000000000000
    MPKH: 0000000000000000000000000000000000000000000000000000000000000000
    CRC0: 9c669ad9
    CRC1: 00000000
    sending 2ndstage to target... f0030002
    waiting for 2ndstage response...
    sending image to target...

とりあえず、オリジナルのカーネルを起動することはできたのですが、なぜか画面が表示されません。画面周りはu-bootで初期化してるのかもしれないです。

また、今回の手順では rootfs もオリジナルのファームそのままなので、画面が出ないものの、中では Android が起動してます。

画面は出ませんがUSBは使えるので、adbでログインすることができます。

kernel はソースがないのでいじれないですが、rootfs はいじれるので、ひとまず簡単にファームの保存、復帰できるイメージでも作ってみますかね。


FT701W で omap4boot が使えるかも??

 OMAP4にはUSBからブートローダを読み込んで起動する機能があります。

前回 FT701W で fastboot mode に入れないか色々試していたときに、電源 OFF 時に USB に接続すると、わずかな時間だけHostPC から、USBデバイスが見えることに気づきました。

$ lsusb
(省略)
Bus 001 Device 066: ID 0451:d00f Texas Instruments, Inc. 
(省略)

このVendorID, ProductID でググってみると、これが OMAP4 の USB ブートの際に使用するデバイスらしいです。

ってことは、自前のBootloaderをこれで流し込めるのでは?

一気に期待が高まりますね!

 

で、USB ブートさせるには HostPC 側で omap4boot と言うツールを使うらしいです。

いきなり動かすのはコワいので omap4boot の中身を調べてみました。

ざっくり書くと、以下のような流れになっているようです。

 

HOST-PC側

  1. 1st bootloader を USB で送り込んで、それをターゲットで起動。
  2. 1st bootloader からの応答 (0x11223344) を待つ。
  3. 応答が来たら 2nd bootloader を転送。
  4. 終了

1st Bootloader (Target)

  1. ペリフェラルの初期化
  2. USB で応答 0x11223344 を返す。
  3. 2nd Bootloader を USB から受信。
  4. ヘッダがあれば解析して Linux kernel として起動

1st Bootloader ではボードごとにペリフェラルの初期化コードが書かれています。

ATAG 作ったり ramdisk の配置とかもやっているので、u-boot だけじゃなく、Linux kernel も直接起動できそうです。

 

まずは 1st bootloader のペリフェラルの初期化処理を FT701W に合わせて作成する必要がありそうです。

pandaboard 用の処理はあるけど、SDRAM、GPIO や IOMUX の初期化を行うようなので pandaboard と同じじゃマズイよなぁ。

xloader も解析かなぁ。。


FT701W の u-boot を攻めてみる

FT701Wファームウェアを覗いてみたらu-boot に fastboot という文字列があったので、どうすれば fastboot のモードに入れるのか色々試してみました。

ですが、そもそもFT701Wにはハードウェアキーが電源キーしかないので、長押しで電源入れるくらいしかバリエーションがありません。

メニューキーやホームキーはタッチセンサなので、静電センサの性格上、押したまま電源入れるというのも考えにくいです。

で、一通り試してみたものの、やっぱりというか、FastBoot モードには入れませんでした。

そこで、u-bootを解析してみることにしました。

文字列のアドレスから色々とアタリをつけながら解析していくと、以下の関数が真を返せばFastbootモードに入れるらしいことがわかりました。

80e8973c:       e59f3124        ldr     r3, [pc, #292]  ; 80e89868 <_binary_bootloader_start+0x9868>
80e89740:       e92d4017        push    {r0, r1, r2, r4, lr}
80e89744:       e5934038        ldr     r4, [r3, #56]   ; 0x38
80e89748:       e3540000        cmp     r4, #0
80e8974c:       0a00000d        beq     80e89788 <_binary_bootloader_start+0x9788>
(省略)
80e8985c:       eb002b11        bl      80e944a8 <_binary_bootloader_start+0x144a8>
80e89860:       e1a00004        mov     r0, r4
80e89864:       e8bd801e        pop     {r1, r2, r3, r4, pc}

アドレスを見てもらうとわかりますが、そこそこ長い関数になります。

ですが、SDドライバで培った逆コンパイル手法で力業で解析すると、こんな感じの関数になりました。

int func_80e8973c()
{
        if (readl(0x4a31c038) != 0) {
                if (readl(0x4a31c044) != 0x800)
                        retrun 1;
 
                printf(" Green key press == Recovery mode \n");
                while ((tmp = readl(0x4a31c018) != 0))
                        writel(tmp, 0x4a31c018);
 
                goto l97bc;
        }
 
        ret = func_80e88ea4();
 
        *(u8 *)(0x80eaf42c + 0x38) = ret;
 
        tmp = (ret - 2) & 0xff;
        if (tmp > 1)
                return 0;
 
        if (ret == 3) {
                printf("System go into recovery mode\n");
                printf("\n Case: \%reboot recovery\n");
l97bc:
                printf("\n Starting recovery img...\n");
//長いので省略
                printf("fastboot: Error: Invalid recovery img\n") ;
                return 0;
        }
        printf("\n");
        printf("System go into normal mode\n");
        printf("\n");
        return 0;
}

真を返すのは、readl(0x4a31c038) != 0 と readl(0x4a31c044) != 0x800 が成り立った時のみのようです。

アドレスが物理アドレスと仮定すると、0x4a31c000 〜 0x4a31cfff は "keyboard" らしいです。(OMAP4430 のマニュアルより)

さすがにキーの配線がどこに接続されているは回路図がないと追えません。

そもそもデバッグボードにしかないキーかもしれないですし。

ひとまず、Linux で上記アドレスを使用しているドライバがあるか調べてみます。

# cat /proc/iomem 
40100000-401f13ff : omap-aess-audio
(省略)
4a314000-4a31407f : omap_wdt
  4a314000-4a31407f : omap_wdt
4a318000-4a31807f : omap_timer.1
  4a318000-4a31807f : omap_timer
4c000000-4c0000ff : omap_emif.0
(省略)

使ってるドライバは無いようです。

つまり、少なくとも起動中に使えているタッチスイッチ等は "keyboard" のデバイスではないと言うことです。

ということは、キーの組み合わせなどの操作で fastboot mode や recovery mode には入れないということになります。デバッグボードか何かにあるキーなのでしょう。残念。