2010年09月20日

FLASHの使い方(案)

MTDのパーティションについて

    細かく分けてしまうと、ウェアレベリングをそのパーティション内でやらざるを得ないという問題が出る。スワップは領域が小さい上に書き換え頻度が多くなることになり、持つこと自体が厳しくなる。そのため、大きな領域にして UBI パーティションとして、その後の分割は後で考えることにしたい。

    UBI 以外は、ブート用と カーネル用のパーティションに分ける。
    ただし、使うのは先頭だけで、隙間をたっぷり取っておく。(
    隙間の使い道はあとで考える。)

      4MB ブート用 (代替ブロック 2)
      60MB カーネル用 (代替ブロック 2)
      残り UBI 用 (代替ブロック 10)

    こんなところでどうだろう。

と書いた。これについてもう少し考察しておきたい。

    最新の案:

    4MB ブート用 (代替ブロック 2)
    60MB カーネル用 (代替ブロック 2)
    残り UBI 用 (代替ブロック 200 for 4Kpage,2GB)




E7002(tcc8902) のファームウェアアップデート方法についてちょっと調べた。ポイントだけ書くと、

  • FWDN というツールでアップデートするが、tcc8902 の USB boot にも対応している。
  • 書き込むデータはいくつかに分割されている。その種類は、
    Boot Loader , Kernel Image, Ramdisk File, MTD(tcc8900_mtd.img :121MB)
  • >MTD については、NAND Data.fai (730KB) というファイルも必要。

FWDN が MTD を外部から書くのだとすれば、バッドブロック処理は必須で、そのための情報が NAND Data.fai のような気がする。(違うかも知れない)。
Boot Loader , Kernel Image, Ramdisk File についても バッドブロック処理があるのかも知れないが、簡単なものではないかと思える。

いま作ろうとしているものも事情は同じ。上記も参考にしよう。

まず、ブート用、カーネル用 の書き換え頻度は少ない。 バッドブロックが新たにできる確率は小さい。それでも 初期状態ですら存在する確率は 0 ではないので、対処だけはしておく。

対処は、簡単なもので良く、mtd ドライバのバッドブロックに対応すれば十分。対応は、書き込みツールと Boot Loader など読み込むコードで行う。Linux の方法を採用しているだけだから、Linux 自体は なにもしなくて良い。

さて問題は、UBI 用である。手持ちの SSD は、32GB/2Kブロック (16K 個のブロック)に対して、1000個ほどの代替ブロックを用意している。2GB/512B ブロック なら 4K 個のブロック数なので、250 個ほどは 代替ブロックが必要という計算になる。にもかかわらず 10個ほどしか用意しないのは、mtd の仕組みは 使わないと思っているから。

問題は バッドブロックだけではない。たとえ再インストールしても いままでの書き換え回数の情報は残したい。

で、それをするためには、UBI は、Linux で必ず更新する..ということにしまうのが一番簡単である。

インストールする際にも、Linux を動かして Linux が自分で UBI を初期化することになる。

そう決めたときの課題は、インストールする内容をどこから持ってくるか。

  • USB から
    インストールは、USBBOOT だけで行なおうと考えている。それならば自由度は高く USBBOOT 経由でデータを転送することが可能ではある。

    ただそうした場合、ドライバーを作成しなくてはならない。これは大分面倒。

      もうひとつは、microSD/SD から。

      これは、どこに置くか決めるだけで面倒ではない。だが、操作のほうが面倒だ。データは PC にあるので、microSD/SD にいちいち書きこまなくてはならない。

      スターンドアローンで アップデートできるなら microSD/SD に置いても良いのだが.. 一部は PC / 残りは microSD/SD というのは避けたい。

    • カーネル用パーティションから

      これが一番簡単。ただ、容量が足りなくなるのが心配だし、容量が無駄に使われるのが嫌な点。

      足りなくなる点については、少し考察してみよう。オリジナルのファームウェアは、圧縮して 20-30MB 。android 2.1(tcc8902) は、60MB ほど。ubuntu を採用した SmartQ5 では、170MB ほど。

      android ですら 60MB なら、個人が用意できる基本ファームウェアがそれ以上になるとは思えない。それでも超える場合は、上の方法を使うということでどうだろう。

    まぁ.. こういうわけで、圧縮したイメージを カーネル用パーティションの隙間におくことにしよう。

    次の問題は、インストーラ。インストーラ用のカーネル と initrd を別に持つというのもひとつの方法だが、正規の initrd に 組み込んでしまうのはどうか?

      あるボタンを押して立ち上げれば、initrd がそれを認識して、インストールを行う。初期化できたところで、正規の mount 処理を動かす。

    こんなかんじ。新しくなっていれば、自動的にインストールするのでも良い。

    どうしても panic するという自体になってしまったら、初期化すれば立ち上がる。

    ただ、ユーザのデータと その下位構造の UBI は勝手に壊さないようにする。ユーザのデータや UBI まで壊れた場合は、確認を求める。No! の場合、その場は電源を切る。後で USBBOOT を使った修復ツールを動かすとか別途考える。

    パーティションの容量配分は、これで良いか?


      4MB ブート用 (代替ブロック 2)
      60MB カーネル用 (代替ブロック 2)
      残り UBI 用 (代替ブロック 10)


    と書いたが、これで良いのだろうか? まず、代替ブロックとはどういう単位で代替するのか? 代替ブロックのために 容量がどれだけ犠牲になるのか知らないといけない。

      ちょっとコードを見てみる。代替ブロックの定義は、get_jz_badblock_table() を call することで取得する。

      これは、mtdblock-jz.c の mtdblock_zone_init() で行っている。
      で、reserved_sectors という変数に 得た値 を (phys_erase_shift - 9) だけ左シフトして格納している。

      どうも reserved_sectors は 512B 単位で 代替ブロックの単位は、消去ブロックサイズ (4Kpage なら 512K)らしい。

        そうなると 4MB の ブート用パーティションは 1MB 取られていることになる。

      次に管理領域。
       total_virt_block = total_phys_block - bad_block_num
      (単位:消去ブロック, total_phys_block は、mtd の size(バイト単位) を phys_erase_shift している。)
      となっているから、reserved_sectors に管理領域が含まれているようだ。

      さて、エラーを見つけたら マークを付けるようだ。これは nand_base.c の nand_default_block_markbad() 。見ると OOB に対して 2 バイト分 上書き?している。

      それはともかく、それをどう変換するのか .. 関数は、mtdblock-jz.c の mtdblock_address_translate() らしい。これは block_lookup[] という配列を使って virt → phys の変換をしている。512KB 単位なら 4GB でも 8K エントリで 32KB しか消費しないからこれで良いのだろう。 --- 問題はそれをどう作っているか? ということになる。

      どうも nandblock-jz.c の mtdblock_block_lookup_map_entry() というのが更新する関数らしい。そして、badblock を見つけたときに どこを割り当てるかというのは、mtdblock_find_free_block() ということらしい。

      なにをしているかというと block_info[] を頭からサーチして、free block の マークが付いているものをさがしている。

      block_info[] をどう作っているのか調べないといけない。ちなみに、erase すると block_info[].lifetime を +1 している。

      このデータをいつどう書き戻しているのかというのは結構重要そう。
      block_info は、

      struct mtdblk_block_info {
      unsgined int lifetime;
      unsgined char tag; /* 0x01: FREE 0x02: BAD 0x04: EMPTY*/
      };

      という構造。mtdblock_zone_init で read_oob して メモリ上の配列として構成しているようだ。

    ここまでの理解は、

    • read エラーを見つけたら 消去ブロック単位で代替する。
    • 代替ブロックは oob を線形サーチすれば見つかる。(管理のための領域は、データブロックにはない)

    カーネル用の領域は、こういう仕組みが役に立つだろう。普通なら 5% の代替エリアが必要だとすれば、6 個ぐらいあった方が良い。書き換え頻度が少ないが 代替の単位が大きいので 2 個では不安なのだが、これで行くことにする。

    それに対して ブート用はどうだろう? カーネルでの書き換えは 4Kpage の場合 512KB 単位になるわけで、4MB で 8 つの エリアがある。壊れれば代替してくれるわけだが、先頭が壊れた場合 代替してくれても困るかもしれない。でも、なにか物理的な先頭ページにアクセスする手段があるのだろう。そうだとすれば、壊れていた場合に mtdblock の先頭にアクセスすると、代替されて 無駄に 1 ブロック使われるという弊害がでるが、気にしないことにする。

    8 個のブロックのうち ブートローダが 1 個。代替に 2 個。5 つのエリア(2.5MB) は自由に使えることになる。

    5 つのうち 少なくとも 1 つはカーネルパラメータを入れたい。(
    2 つ 3 つあっても良い。)

    残りは、u-boot を使いたくなった場合に使うことにする。一応 2 個のエリア (1MB) 確保できているから大丈夫だろう。

    最後に UBI 用についてなのだが、512KB 単位で代替しているわけがない。10 個あっても UBI を通して使う限り関係ないはず。

    mtdblock としてアクセスした場合に 代替されてしまうかも知れないのだが、そういう場合も、UBI を通せば関係ないような気がする。

    というわけで UBI もこのままで良いだろう。

      追記: どうも良くないようだ。

      badblock の処理は 下位レイヤに従う。... どうも badblock が出来にくくするために ウェアレベリンングを行うのであって、badblock が出来てしまえばすなおに代替するようだ。

      そうであれば 5 % の 200 個 必要そうだ。これは 4Kpage,2GB の場合で 2Kpage や 4GB なら倍の 400 個。


      実際の OOB の代替ブロックを示すデータについて:

      OOB に格納する形式は、

      struct mtdblk_fake_fsbuf {
      unsigned int block_addr_field1;
      unsigned int block_addr_field2;
      unsigned int lifetime;
      };

      という形式で、oob のオフセット 2 から格納されている 。
      block_addr_field1 , block_addr_field2 に virt_block 番号が入っていて、読み出したとき同じなら正しいデータと見做す。
      lifetime は 消去回数。

      このデータがどこにあるかというと、各消去ブロックの先頭ページに対する oob 。次のページから CONFIG_MTD_OOB_COPIES 分だけ同じデータがあり、壊れていたら コピーを見ることになっている。

      あと、代替ブロックが出来ていたら、代替ブロックの方を常に見ないと整合性が取れない。壊れているという mark はどこにあるのか?

      どうも nand_default_block_markbad() という関数でこの処理をやっているらしい。

      .. 見てみると、代替する場合は、各消去ブロック の 127ページ 目の oob の先頭から 2 バイトを 0 にする。判断は、先頭の 1 バイトが 0xff 以外だったとき 代替されていると判断する。
      (そういえば、バッドブロックのコードは、usbboot にもあった)

      これで、OOB の 先頭から 14 バイト分がどう使われるかは分かった。( そして 4Kpage で 8bit-BCH の場合は、 オフセット 24 から 最後まで ECC が入る。)

    (つづく)
posted by すz at 16:58| Comment(0) | TrackBack(0) | Jz47xx(Linux)

2010年09月19日

MinGW環境でmipsel-gccをビルド

MinGW環境でLinux をビルドするつもりはないのだが、USBBOOT は動かせるようにしたいし、stage1/stage2 とかぐらいはビルドしたい。

で mipsel-gcc をビルドしてみることにした。

ちなみに、使っている MinGW/MSYS 環境はずいぶん古い。最新の環境なら少し楽できるかも。

1. binutils-2.19

    $ ./configure --target=mipsel --prefix=/mingw
    $ make
    これで良いはずだが、info が作れずエラー。
    bfd/Makefile SUBDIRS から doc を除くことでビルドできた。

    $ make install

2. gmp-4.3.2

    gcc をビルドするには、gmp と mpfr が必要だが、古いのでない。

    $ ./configure --prefix=/mingw
    $ make
    $ make install

3. mpfr-2.4.2

    $ ./configure --prefix=/mingw
    $ make
    $ make install

4. gcc-4.2.4

    最初に gcc-4.4.4 を試した。-- make-3.80 以上が必要なのだが、古い環境なので 3.79 。新しい make をビルドしても動かなかったので、gcc-4.2.4 に変更。

    $ ./configure --target=mipsel --prefix=/mingw --enable-languages=c
    $ make

    libgcc2.c の _muldi3.o の make で

    ./tm.h:9:27: error: config/elfos.h: No such file or directory
    ./tm.h:10:31: error: config/mips/mips.h: No such file or directory
    ./tm.h:11:30: error: config/mips/elf.h: No such file or directory
    ./tm.h:12:23: error: defaults.h: No such file or directory

    なんてエラー

    gcc/Makefileの LIBGCC2_INCLUDES

      LIBGCC2_INCLUDES = -I/d/AVR/gcc-4.2.4/gcc

    なんて風に MinGW 流のパスを付けたら先に進んだ。

    次に libssp/ssp.c で O_RDONLY や ssize_t がないとエラー。

    gcc 自体の ビルドは終わっている。無視して

    $ make instll

    使わないはずなので、configure に --disable-libssp を追加しても良い。

確認

    linux は、scripts の HOSTのプログラムのビルドでエラー。-- mmap 使っているので無理だった。
    usbboot の xburst_stage1 は OK 。

ファイルが足りないかも知れないのだが ... 最小限のバイナリを置いておく。→ 再作成したので削除 。再作成版は後ろに記述。

... そういえば、PIC32 も mips 。役に立つのだろうか?

    "MPLABо C Compiler for PIC32 MCUs User's Guide" (pdf) に説明がある。汎用なので、PIC32 用のマクロが定義されていないぐらい? そういえば mips16/mips16e は気にしていなかった。.. チェックしたら binutils も含め mips16/mips16e は、使えなかった。

    MIC32用のビルドは、--prefif,--enable-language に加えて、
     --target=pic32mx --with-dwarf2 --enable-multilib --disable-libssp
    ぐらいを付ければ良さそう。


再度ビルドに挑戦中。

ここみて、オプション変更。

1. binutils-2.19.1

OpenWRT のパッチ集が ここにある。

200-mips_non_pic.patch というのが気になる。関係ないのも多いが 一応数字の順に全部あてる。



    $ mkdir build; cd build
    $ ../configure --target=mipsel --prefix=/mingw --disable-nls \
    --without-included-gettext
    $ make
    (info が作れずエラー) → bfd/Makefile SUBDIRS から doc を除く。

    gas でも、info が作れずエラー。
    gas/Makefile SUBDIRS から doc を除く。

    ld も引っかかる。どうやら余計なパッチを当ててしまったようだ。

    $ make install


gmp-4.3.2/mpfr-2.4.2 は上記参照

4. gcc-4.2.4

OpenWRT のパッチ集が ここにある。

随分多いのだが、当たらないものもあるし、c++ 用のものも多い。ビルドは、c だけにすることにして

    820-libgcc_pic.patch
    910-soft-float.patch
    920-soft-float.patch
    930-eabi_fixes.patch
    951-bug_37014.patch
    952-bug_34762.patch

だけにする。


    $ mkdir build; cd build
    $ ../configure --target=mipsel --prefix=/mingw \
    --enable-languages=c \
    --disable-multilib --disable-decimal-float --with-float=soft --with-abi=32 \
    --with-tune=mips32 --with-dwarf2 \
    --disable-__cxa_atexit --disable-libssp --disable-tls --enable-static \
    --disable-nls --disable-threads
    $ make
    (libgcc2.c の _muldi3.o の make でエラー) → gcc/Makefileの LIBGCC2_INCLUDES 編集
    $ make
    $ make install


パッチは、tar+gzip で固めたのを 次に置いておく。


バイナリ (最小限 -- 作成中)
posted by すz at 05:09| Comment(0) | TrackBack(0) | Jz47xx

2010年09月15日

ベースバージョンをr237に変更

qi-hardware が ingenic が出しているソースを Ingenic Linux 2.6.31.3, READ ONLY: live Ingenic development tree として管理している。

いままでベースにしていた r108 は 4 月頃にここから svn で取得したものだが、大分違ってきているので、再度 svn でダウンロードした。(r237) 。

どうせ全然動かせていないし、(追加はしたが)変更もしていないに近いので今のうちにベースを上げておこうとおもう。

例によって 次に整理したものを置いておく。


これをベースにして、いまで使ってきた config ベースでビルドできるようにして、さらに ソース Tree の シュリンク版も作る。

さて、最初の問題は、JZ4750L ではビルドできない所がある点。あと、JZ4750L だけサポート外にされている Kconfig がある JZCHAR と MMC(HOST) 。

jz_ubcomm は入れずに、これらだけを直す変更をしたパッチを作ることにする。

また、JZ4750 がどのようにコンパイルされるか知りたいので、JZ4750 の apus もビルドできるようにしておく。(ただし USB HOST や ETHERNET , WIRERESS , YAFFS 関係 と NFS_V4関係は入れない )

ECC 関係で変なところがある。CONFIG_HW_BCH_ECC=y とすると YAFFS の中のコードを call するのだ。

    -- 適当に取ってきたスナップショットなので、コードが中途半端なのかも。

.. それはともかく、JZ4725B は JZ4750 と同じ機能を持っているのかどうかが重要だ。

データシートを見てみると、JZ4725B は、4/8/12 bit ECC をサポートしているのに対して JZ4725 は 4 bit ECC しかサポートしていない。データシートを見ると記述がいろいろ違うのだが、

  • JZ4740 まで Hamming or Reed-Solomon ECC をサポート。
    -- CONFIG_MTD_HW_HM_ECC or CONFIG_MTD_HW_RS_ECC
  • JZ4750 4/8/12 bit BCH ECC をサポート
    -- CONFIG_MTD_HW_BCH_ECC (CONFIG_MTD_HW_BCH_4BIT or CONFIG_MTD_HW_BCH_8BIT)

ということなのだろう。APUS は CONFIG_MTD_HW_BCH_8BIT を使っており、JZ4725B も同じで良いはず。

JZ4750L(JZ4725B) を同じにするには、ソースで JZ4750L が仲間はずれにされているところを修正していかなければならない。Kconfig だけでなく nand_base.c にもこのようなコードがあった。

    drivers/char/Kconfig の RTC_JZ , drivers/usb/gadget/Kconfig の UDC_USE_LB_CACHE , あと、driver/usb/gadget/udc_hotplug.c
    他にもあるが、touch-panel サポートなど、JZ4725B にない機能とかは外す。

ところで、ECC の種類の意味が判ったが、それがどのように OOB に格納されるのか?

used free
off len off len
2Kpage
Hamming 40 24 22 38
Reed-Solomon 28 36 2 26
4bit-BCH(?) 24 28 2 22

4Kpage
Hamming 80 48 2 78
Reed-Solomon 28 72 2 26 100 28
4bit-BCH 24 56 2 22 80 48
8bit-BCH 24 104 2 22

nand_base.c に テーブルがあって こんな風に定義されていた。(Hamming はオリジナルからあるが、それ以外は ingenic が定義している)

  • 8bit-BCH は、4Kpage で 104 バイト使用する。512B あたり 13バイト。4bit-BCHは、512B あたり 7 バイト。RS は 9 で、HM は、6 。

  • あとオフセット 0,1 の 2 バイトは free じゃないし特定の目的に使われるようだ。

  • 2Kpage では、8bit-BCH は 4bit-BCH と同じ定義 .. 入らないのだが ..

それはそうとして、USBBOOT の OOB の定義はこれとどう関わるのだろう? あと NAND からの boot では、ECC をチェックすると書いてあるが、どの ECC を使うか分かるのだろうか?
疑問は尽きない。特に JZ4750 系の資料を持っていないので、カーネルのコードから推測する以外にないのがつらい。

まぁ、ここではコードの詳細に入りたくないのだが ... この部分が変なので、ベースとしてどう扱おうか 困っているので、ちょっと見ているわけだ。でも、ついでなので続ける。

前からの疑問がある。USBBOOT の config で NAND_ECCPOS という項目があるのだが、これだけどう扱って良いのかわからない。

512B 毎に ECC を取って 6-13 バイトのデータを OOB に格納するらしいということは分かった。で、オフセットはどうも ECC の種類や ページサイズ で違うということも分かった。

で、NAND_ECCPOS とどう関係してくるのだろう?

    ちょっと USBBOOT の方を見てみる。

    NAND_ECCPOS は、stage2 で使う。これが nand_4750_init() のパラメータとして渡り eccpos という変数に格納される。(もし 0 なら 3 を入れておく)

    nand_4750_init() では、bchbit という変数も持っていて、それもパラメータで受ける。デフォルトは 8bit 。
    -- config に NAND_BCHBIT というのがあった。

    これが 8bit の場合 par_size = 13 としていて、それ以外(4bit) では 7 としている。

    オリジナルファームウェアがどのように使っているのか定かではないのだが、どうも 24 をいれればよいらしい。

    2Kpage だと 入らないので 4bit 以外の選択はないが、4Kpage はどうなのだろう? 8bit なのか 4bit なのか?

      対応しようと思っているものはほとんど 4Kpage なのだが、Neo Slim 3000 だけが 2Kpage。config で定義しないといけないので、とりあえず 4bit としておく。

    もうすこし見てみる。パラメータに NAND_BADBLOCKPOS(defualt 0) と NAND_BADBLOCKPAGE(default 127) がある。

    これは、消去ブロック(128ページ分) 全体を バッドブロック とするための情報で 127ページの oob の先頭 1 バイトが 0xff でなければ バッドブロックと判断している。

    それとは別に nand_mark_bad_page() という 関数があって page 単位で バッドブロックとする処理がある。これは、データと OOB に対して 0x00 を Write する。(バッドブロックなので 結果が 0x00 になるとは限らない )

    消去ブロック全体を バッドブロックとする nand_mark_bad_4750() では、nand_mark_bad_page() を NAND_BADBLOCKPAGE に対して行っている。

      NAND_BADBLOCKPAGE を 128 にすると、ブロックの最初 2 ページと 最後 2 ページに対して nand_mark_bad_page() する。

    ちなみに、Jz4740 では、PAR_SIZE は define で 9 になっている。ecc_pos は設定できるがデフォルト 6 で 2Kpage を想定。Reed-Solomon 固定ということなのだろう。ただし、offset のデフォルトは (ingenic の)Linux と合わない。

だいぶ分かってきた。

YAFFS の中のコードを call する点については、r108 → r237 で、nand_sw_bch_ops() という関数が追加されたことに関係するもので、nand_base.c と jz4750_nand.c だけを r108 ベースに戻してしまえば問題なくなる。

これで、コードのベースを確定できた。



ingenic オリジナル r237 の ソース tree に対して、linux-jz4725b-r237-base.patch を当てたもの から FILES-shrinked.list のファイルだけにしたものが開発のベース。

付属の config_jz4725b_base, config_apus_test, config_lyra_test で ビルドできることを確認。(その他の config はたぶんファイルが足りない)


こちらは、上記のパッチをあてて、shrink した
ソース tree 。

さて、OOB についてもう少し。

    A-41 や P5-5 の OOB を dump すると次のようなデータになっている。

    A-41
    011700 ff ff ff ff ff ff ff ff 57 59 4b b0 8b e5 53 90
    011710 9e 57 e5 96 be 61 37 3e 97 c8 45 27 dc 88 1d c6
    011720 14 58 75 2d 33 8a d6 f5 55 fe c5 62 53 09 3f 85
    011730 e3 b4 ac 14 bc 67 42 d0 77 64 0e 8d 39 f3 e6 98
    011740 96 bc 00 53 97 3b b8 0e 16 57 59 4b b0 8b e5 53
    011750 90 9e 57 e5 96 be 61 37 3e 97 c8 45 27 dc 88 1d
    011760 c6 14 58 75 2d 33 8a d6 f5 55 fe c5 62 53 09 3f
    011770 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
    P5-5
    026180 ff ff ff ff ff ff ff ff 77 6d 9f 45 e5 81 c5 4e
    026190 14 c6 58 f0 9e 81 bb 91 79 8a 41 9b bf 82 5d ce
    0261a0 1d 91 8f 5f cd 5f a2 29 eb de 63 1e 87 2a 13 b6
    0261b0 ce ce d8 36 96 ae 3c 74 3e 99 75 78 e0 a4 f3 33
    0261c0 95 5b 31 19 55 6e 5b c0 cc 27 85 c0 fc 4b b5 6d
    0261d0 6f a6 31 57 f7 31 7b f6 83 fd ab 17 7f ca 32 d4
    0261e0 b7 5b 23 e0 2d 5f f2 a8 66 96 f9 eb 16 8c 7f b7
    0261f0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
    A-33
    061400 ff ff ff ff ff ff ff ff 2a 18 bd 90 dd e4 90 3d
    061410 6d f2 d3 fd 53 44 aa 74 52 9e cf 9b b0 71 81 77
    061420 6f 05 44 aa 74 52 9e cf 9b b0 71 81 77 6f 05 44
    061430 c8 a1 c2 41 0f af ba e1 ab 6a 7c 73 44 aa 74 52
    061440 9e cf 9b b0 71 81 77 6f 05 44 aa 74 52 9e cf 9b
    061450 b0 71 81 77 6f 05 33 86 fb 18 0a ce 41 84 a3 5f
    061460 b4 1f 60 44 aa 74 52 9e cf 9b b0 71 81 77 6f 05
    061470 44 aa 74 52 9e cf 9b b0 71 81 77 6f 05 44 aa 74

    先頭 8 バイト目からデータがはじまり、(最初の2つ)後ろ 16 バイトは 0xff 。データの量は 104 バイト。

    -- ということは、8bit BCH を使っており OOBPOS=8 ということだ。

    104 バイト以外が全部 0xff ということは、書き換え回数などの管理データは、まだ初期状態? (A-33 は、後ろ 16 バイトにデータが入っている )

    こういうデータだから Linux の管理に合わず Linux で NAND を使うなら共有できない。( ECC の位置だけ無理やり合わせても、管理データの使い方が同じとは思えないので無理 )

    ちなみに、2Kpage の Neo Slim 3000 を見てみたが、全然パターンが違う。原則にも合わない。ひょっとしたらバグで ちゃんとデータが取れていないのかも。

    Neo Slim 3000 の分析は後回しにしようと思う。


追記:jz_ubcomm-001 パッチを作った。

linux-jz4725b-r237-base をいれた上でこのパッチを当てる。

jz_ubcomm は、とりあえず作った分まで 入れた(= 動かない)。

いままでは、f4750l を借りて入れていたが、
CONFIG_JZ4725B_NS3K=y
とかした上で、board-ns3k.c board-ns3k.h なども作って入れることにした。

追加した config は、
CONFIG_JZ4725B_NS3K
CONFIG_JZ4725B_A41
CONFIG_JZ4725B_A33
CONFIG_JZ4725B_P55
の 4つで、board は、board-ns3k , board-a41 だけ作った。
(一応将来の変更も考えて、JZ4750L_NS3K ではなく、JZ4725B_NS3K とした。使わないが、SOC_JZ4725B も作ってある。)

あと デバッグ用に jz_backlight() というのを作ったが、apus , lyra にはないのでビルドできなかったので、スタブを入れてビルドだけはできるようにした。

board-ns3k.h をチェック

    JZ_EXTAL : 水晶の周波数を入れる。

    APUS は、24MHz , LYRA(4740) は 12MHz 。-- では JZ4725B は? ... とりあえず USBBOOT で 12MHz の設定で動作しているので、12MHz で良いだろう。( 動かし出したら時刻のずれから正確な値が分かるはず。)

    GPIO_XX : 各種 GPIO の定義

    GPIO_SD1_VCC_EN_N
    GPIO_SD1_CD_N (MSC1_HOTPLUG_PIN)
    GPIO_SD1_WP (MSC1_WP_PIN)
    GPIO_DC_DETE_N
    GPIO_CHARG_STAT_N
    GPIO_DISP_OFF_N (LDC_REV ?)
    GPIO_USB_DETE (GPIO_UDC_HOTPLUG)
    GPIO_LCD_PWM

    MMC/SD に 電源を供給する スイッチがあるらしい。-- 考慮してなかった。Write Protect も。充電IC の STAT にも普通つながているものらしい。DC デテクトも USB の専用機能でできるものだとばかり思っていた。LCDの OFF 機能だけは、LCD の線から選ぶはずだとは思っていた。どうも 思っていたより 4-5 本余計に必要なようだ。 --- JZ4725B では、とても厳しいはずだ。

    ちなみに LCD 関係は、drivers/video/jz4750_lcd.h で定義する。

    それ以外にオーディオ関係(スピーカ ON/OFF)があるはずだが .. どこでるのだろう?


追記:NAND のパーティション

NAND の パーティションは、drivers/mtd/nand/jz4750_nand.c で定義している。

機種情報を定義したので パーティションも一応定義しておこうと思う。

まず、最初の問題は、オリジナルファームウェアと 共存するか否かを決めないといけない。

今まで調べてきた限りでは、無理という結論で。好きなように使おうと思う。

APUS を見てみると、2GB を

    4MB ブート用 (代替ブロック 2)
    4MB カーネル用 (代替ブロック 2)
    504MB rootfs 用 (代替ブロック 10)
    512MB DATA 用 (代替ブロック 10)
    1024MB VFAT用 (代替ブロック 10)

としている。

こうやって細かく分けてしまうと、ウェアレベリングをそのパーティション内でやらざるを得ないという問題が出る。スワップは領域が小さい上に書き換え頻度が多くなることになり、持つこと自体が厳しくなる。そのため、大きな領域にして UBI パーティションとして、その後の分割は後で考えることにしたい。

UBI 以外は、ブート用と カーネル用のパーティションに分ける。
ただし、使うのは先頭だけで、隙間をたっぷり取っておく。(
隙間の使い道はあとで考える。)

    4MB ブート用 (代替ブロック 2)
    60MB カーネル用 (代替ブロック 2)
    残り UBI 用 (代替ブロック 10)

こんなところでどうだろう。

ところで、カーネルは、zImage を カーネル用パーティションの 先頭から 置く ことにして、ブートローダをどうするか?

実をいうと U-BOOT は使うのをやめることにした。

開発用は USBBOOT でいける。NAND からのブートも stage1/stage2 をベースにすれば自分で作れる。

U-BOOT が持っている高度な機能は使わない/使えない。

  • ファイルシステムからの読み込み
    UBI の上に構築された 、ファイルシステムを読めないといけないので無理と判断。その機能を使わないなら ベタイメージのロードなので、stage2 でもできる。
  • シリアルのオペレーション
    普通は開発用に シリアルを使うのだが、使わずに USBBOOT でなんとかすると決めた。USBBOOT を使うのであれば NAND に プログラムを置く必要はなく、U-BOOT の出番はない。


ちなみに、stage1 は、メモリの初期化など最低限度のハードウェアの初期化をする。それ以降なら メモリを使える。

stage1 の先頭は、ハードウェアの config 情報が入っている。これをバイナリに埋めておけば、ロード→実行 で 最低限度のハードウェアの初期化が終わるわけだ。

現在のサイズは 6KB 。stage2 をロードするコードを入れないといけないが 8KB 以内にできそうだ。

stage2 といっても 最低必要なのは、カーネルとカーネルパラメータをロードして 制御を渡すだけのもの。

とは言っても多少の機能は付けるつもり。

  • USB-BOOT に使うボタン(A-41/33 なら MENU) と ソフトウェア電源ボタン (A-41/33 なら PLAY/PAUSE) だけは 全部の機種で使えるので、多少のオペレーションもできるだろう。

  • LCDを扱うのは面倒だが、バックライトだけは使える。点滅させたりして、エラーを知らせることは出来る。


ところで、Nand からの ブートについて。

Jz4725 を使う SAKC のページに 0x80000004 から開始するということが書いてあったのだが ...

Neo Slim 3000 の先頭は

00: ff 55 55 55 55 55 55 55 ff ff ff ff 01 00 11 04
01: 00 00 00 00 21 e0 e0 03 00 00 e9 8f 21 e0 20 01
02: 00 80 1d 3c 00 40 bd 37 00 80 19 3c b8 06 39 27

となっていて、命令が入っているとは思えない。不思議に思っていたのだが ... u-boot のコードを見たら理解できた。

u-boot の cpu/mips/start.S を説明すると...

    オフセット
    0-3 : NAND が 8bit バスの場合 0xff,0x55,0x55,0x55
    4-7 : 常に 0x55,0x55,0x55,0x55
    8 : NAND_ROW_CYCLE==3 の場合 0xff
    9 : NAND_PAGE_SIZE!=512 の場合 0xff
    10 : NAND_PAGE_SIZE==2048 の場合 0xff
    11 : 不明
    12-15 : 最初の命令

ということらしい。上記 は、Neo Slim 3000 の例だが、A-41, A-33 ともに全く同じだった。

オフセット 8-11 は all 0xff なので、上記とは少し意味が違うようだが、とにかく 元の機種と同じもの -- all 0xff にすれば良いのだろう。

逆に 0xff,0x55,0x55,0x55,0x55,0x55,0x55,0x55 で始まっていないものは、Jz4750系の ROM イメージではない。

    実をいうと、各機種の ROM イメージのバックアップを取ってあるのだが、P5-5 だけ全然違う。... どうも失敗したようだ。

    追記:何回やっても違う。
    先頭はこんなパターン。

    00: 80 80 1f 3c 00 00 ff 27 00 90 80 40 00 98 80 40
    01: 80 00 09 3c 00 68 89 40 40 00 08 3c 00 fc 08 35
    02: 00 60 88 40 03 00 08 24 00 80 88 40 00 80 08 3c
    03: 00 40 09 35 00 e0 80 40 00 e8 80 40 00 00 08 bd

    256MB を 2 回 ダンプして cmp をかけ 不一致が起きるのは、107950 MB のところ。(USBBOOT で電源を入れるだけでなぜ不一致が起きるのか分からないが 他のマシンでも起きる ... それはともかく 頭の方はいつも同じ )
    だからと言ってこれでブートできるとは思えないのだ。... うーん困った。(バックアップが確定しないとイジる気が起きない)

ここまで分れば、nandbootの head.S などを参考に自作したほうが、見通しが良く便利。

jz_ubcomm-002 パッチ

まだまだ整理途中。動かそうともしていないし、ubcomm も無変更。


linux-jz4725b-r237-base をいれた上でこのパッチを当てる。

  • 常に base からの差分でパッチを作る予定 。
  • もし shrink 版で足りないファイルが出てきても、パッチは存在するものとして作成する予定で、エラーになったらオリジナルから取ってくる必要がある。
posted by すz at 23:12| Comment(0) | TrackBack(0) | Jz47xx(Linux)

2010年09月14日

三脚固定用ガジェット

三脚に PMP などを 固定するものを見つけたのでメモ。


Universal Clamp Mount for Tripods $2.71

DealExtreme で見つけたもの。クランプになっていて 3.8cm までのものを挟める。フラッシュライトを固定したりするのに便利。

    クランプで挟めるものを PMP に貼りつけたら 良いのかも知れない。ゴム足とか .. そう言えばダイソーで買った フェルトのシールがあった。こんなものでも 剥がれなければ使えそう。


Anti-rust Tripod for MP4/Cellphones/Digital Cameras $6.30

これは、PMP とかを固定するもの。100 均で買える三脚と同じ三脚が付いている。

買ってみたら、写真と違ってラバーが付いていた。A-33(51mm) は挟めた。他のものはまだ試していないが、P5-5/PMP3100(55mm) とか Dingoo A320/A330(55mm) は挟めると思う。

あまり、金具を伸ばせない。挟めるのは 60mm ぐらいまでのようだ。


三脚固定用ケータイホルダー 387円 (メール便 非対応)

これは上海問屋でみつけた。42mm 〜 85mm のものを挟めるそうだ。Neo Slim 3000 (70mm) はこれでないとダメかも。

角度を 変えることができる普通の三脚なら、上海問屋ケータイホルダーが良さそう。

角度を変えられないスタンドとか 100均のものとかを使うなら DealExtreme のものが良さそうなのだが ... Neo Slim 3000 は無理。
posted by すz at 00:15| Comment(0) | TrackBack(0) | 日記

ソースをシュリンク

Linux のソースコードは大きい。bzip2 を固めたものでも 61MB もある。これを展開すると 420MB にもなる。

    420MB は、du で調べた値。ファイルシステムの消費量としてみる場合は、展開する前後で df で調べる。ext3 で試してみると ... 414MB で差はあまりなかった。ext3 は良いが、VFAT の microSD に 閲覧用として展開すると ひどいことになりそう。

ディスクスペースを使うのも問題だが、これだけのファイルを作ったり消したりするのは、SSD や (SD/microSD) ではやりたくない。

さらに diff をとったり grep するのに、対象ファイルが多いのは 遅くて不便。あと、grep で関係ないファイルがヒットすることも無くなる。-- これができると便利なときがあるかも知れない。(常に便利とは限らない)

... というわけでシュリンクした ソース tree を作ってみた。

方針として、ファイルを変更しないという条件を付ける。変更すると 差分が違ったりして diff を見るのが面倒になるだけでなく、何度も同じことをするのが億劫なのだ。自動化するツールがないとやってられない。

さて、どのようにやるか ...

ソースコードの依存関係は、ビルドした後 .xxx.cmd ファイルに含まれている。(注意:ビルドするときに作られるので、モジュールも含め 一度完全にビルドしないといけない)

.xxx.cmd ファイルを cat で全部くっつけて、sort したものをまず作る。


cat `find . -name .*.cmd -print` | sort | uniq > file

こんな感じ。

できたファイルを エディタで 編集する。 $(wildcard ...) から始まるものと ホストのファイル を削除すると ... ソースコードがある ディレクトリのヘッダファイルが先頭になる。そして相対パスの ソースコードが続き $(deps...) で始まる行になるので、$(deps ...) 以降を削除する。

これを元にして

  • 一部 .. が含まれているので手動で変更。
  • 絶対パスを linux からの相対パスに変更(スクリプト等で変換)。
  • 最後の スペース + \ を削除(スクリプト等で変換)。
  • モジュールは .mod.c とかになっているので .mod を 削除

という作業をする。

できたものに対して sort + uniq すると 2000 行ほどのファイルになる。

これが第一のファイル群。


tar -zcvf ../file1.tar.gz `cat file`

などとして、tar で固める。

次に Kconfig* Makefile* Kbuild* を tar で固める。

tar -zcvf ../file2.tar.gz `find . -name Kconfig\* -print` `find . -name Makefile\* -print` `find . -name Kbuild\* -print`


これが第二のファイル群。これも 2000 個ほどになる。


あと scripts と arch/mips/boot と drivers/video/logo を tar で固める。

tar -zcvf ../file3.tar.gz scripts arch/mips/boot drivers/video/logo

これが第三のファイル群。

TOP ディレクトリを作成し、第一〜第三のファイル群を展開。

コンパイルしてみる。

まずは、make distclean がエラーにならないか確認。.. たぶん

    include/asm が シンボリックリンクになっていないのでエラーになる。asm を消す。

これで通るはず。

次に make zImage してみると ...

  • make は進むが、arch/x86/include/asm/unistd_32.h がないと言われるので、コピーしておく。
  • 次に kernle/timeconst.pl がないと言われるのでコピー
    これでだいぶ進むが ..
  • drivers/char/cp437.uni がないといわれるのでコピー。fs/nls に nsl_cp932.c nsl_cp936.c nsl_cp437.c のどれかはないはずなので ついでにコピーしておく。
  • drivers/char/defkeymap.c がないと言われる。defkeymap.c_shipped と defkeymap.map をコピー
    これで .. zImage まで作成できたはず。


さて、これはこれで良いのだが ... config を変更するとファイルが足りなくてエラーになる。

第一のファイル群を作成するときに、複数の config で 作ると良い。

作成中の JZ4725B 用の config と lyra から YAFFS2 を抜いた config で 作った シュリンク版とオリジナルの規模比較

tar+bz2 のサイズ 展開後サイズ ファイル数
オリジナル    61.5MB 420MB 29652
シュリンク版 7.4MB 63MB 5770


展開後サイズで 15 % 程 (ファイル数で 20% ほど) に縮小できた計算。

    ファイル数が相対的に多いのは、余計な Kconfig/Kbuild/Makefile が含まれているため (平均ファイルサイズが小さくなる) 。

    必要なものだけ 選び出すスクリプトを作れば、多少減らせるのかも知れない。さらに自動で編集してくれて、本当に必要なものだけに出来るのであれば、それを使っても良いとは思っている。--- だがそういうのを作るは面倒だしいまのところはパス。


ファイルのリストを linux-2.6.31.3-ingenic-r108-shrinked.files.gz に置いておく。参考まで。

追記:

arch にある Kconfig とか があるのでターゲットでない arch も残しているわけだが ... 試してみたら

    ia64 mips s390 um x86

を残せば良さそう。

試し方は、1つのディレクトリを mv で rename して make distclean が通るかどうかを見る。エラーになれば消せない。

最終的には、実際にカーネルをビルドしてみる。だめなら tar ファイルからファイルを戻す。

まぁそこまで消せたとしても 減るファイル数は知れている。
drivers にディレクトリが沢山あるのでこちらのほうが効いてくる。-- だが subdir の Makefile が drivers/Makefile からインクルードされているので、ファイルの編集をしないと消せない。( arch は基本 TOPみたいなものだから 例外を除いて消すことができる。)
posted by すz at 00:14| Comment(0) | TrackBack(0) | Jz47xx(Linux)

2010年09月09日

configのチェック

Jz4725B 用のカーネルを作るには、正しい config ファイルが必要。他の Jz47xx のボードの config は参考にするものの、自分用の config を 作っていかないといけないと考えている。

とりあえずは、f4750l_defconfig をベースにしているが、デバイス周りは全然だめだと思うし、参考にする ボード を 1 つ決めておこうと思う。

Jz4730 のものは古そうなので除外。Jz4750D は laptop みたいなものがターゲットのように見えるので除外。Jz4750 は良さそうだが、機能が多いので むしろ Jz4740 のほうが良さそう。

というわけで、Jz4740 に どういうものがあるかまずチェック。

  • leo SUSPEND, UBI が disable
  • lyra SUSPEND, UBI が定義されている。
  • pavo SUSPEND, UBI が disable
  • virgo SUSPEND が disable


どういうボードなのか理解したわけではないが、lyra を基準にしてみようと思う。

まずは、 f4750l のチェック。あとで lyra との違いをチェックしようと思う。

一般的な設定:CPU関係

    CONFIG_JZ_FPGA=y -- JZ4725B は FPGA ではないから 外したいが、なにをするのに使っているかチェックした後にする。

      使っていない。外してよい。

    CONFIG_CPU_HAS_PREFETCH=y -- prefetch を持っているが果たして性能が上がるのか? SDRAM は、BANK を使いこなすと アクセスをオーバラップさせてスループットを向上できるが、Jz47xx では BANK が上位ビットで 使う物理ページがランダムにならないと オーバラップできない。その条件は 使っているうちにランダムに近くなるのでクリアできそうだが。そもそも Jz47xx のメモリコントローラに オーバラップできる機能があるのか疑わしい。
    それでも どうせアクセスするようなデータなら prefetch しておくのは有効かも知れない。Linux が動いた後の話になるが、外してどう性能が変わるか見てみたい。

    CONFIG_HZ_100=y -- HZ=100 なのか。これも覚えておこう。

    CONFIG_ARCH_HIBERNATION_POSSIBLE=y
    CONFIG_ARCH_SUSPEND_POSSIBLE=y
    CONFIG_PM=y
    CONFIG_PM_SLEEP=y
    CONFIG_SUSPEND=y
    CONFIG_SUSPEND_FREEZER=y
    # CONFIG_HIBERNATION is not set

    このあたり、サスペンドがちゃんと動くかどうかをチェックする時のキーワード。

    ところで、SIMD 命令の XMUが使う 専用のレジスタについて、カーネルは感知しないことになっているようだ。CONFIG がなにもない。-- 1 プロセスが使うことのみが前提で、それを守る仕組みもないから自己責任で使うことになる。

    Linux カーネルで でコンテキスト切り替えしてくれたら、描画ライブラリでも使えるし、カーネルでのメモリコピーにも使えるのに とか思う。
    ただ、フローティングポインタレジスタの制御ように、最適化しないと使わないプロセスの プロセススイッチが遅くなってしまう。
    でも、そういうコードを作るには、情報が足りていない。

    JZ4725(無印)の config があった。(dipper)

    CONFIG_JZ4725_DIPPER=y
    CONFIG_SOC_JZ4740=y
    CONFIG_SOC_JZ4725=y

    なんて定義している。

    CONFIG_JZ4725B_NS3K=y
    CONFIG_SOC_JZ4750L=y
    CONFIG_SOC_JZ4725B=y

    なんてするのが良いのだろうか?



一般的な設定: Linux


    FAT_DEFAULT_CODEPAGE=437

    CONFIG_NLS_CODEPAGE_437=y
    CONFIG_NLS_CODEPAGE_936=y
    # CONFIG_NLS_CODEPAGE_932 is not set

    このあたり修正しておくべき。

    CONFIG_NET

    NET は入れる。いれないのは論外だと思うが、例えば lyra は入っていなかったりする。

    CONFIG_NFS_FS=y
    CONFIG_NFS_V3=y
    CONFIG_NFS_V3_ACL=y
    CONFIG_NFS_V4=y
    # CONFIG_NFS_V4_1 is not set
    CONFIG_ROOT_NFS=y
    CONFIG_NFSD=y
    CONFIG_LOCKD=y
    CONFIG_LOCKD_V4=y
    CONFIG_NFS_ACL_SUPPORT=y
    CONFIG_NFS_COMMON=y
    CONFIG_SUNRPOC=y
    CONFIG_SUNRPC_GSS=y
    CONFIG_RPCSEC_GSS_KRB5=y

    NFS は使いたいが、V3 までで良い。V3_ACL もいらない。
    NFS を root にできるようにしておく。
    NFSD/LOCKD は module で良い。

    # CONFIG_CIFS is not set

    CIFS は、モジュールで いれておく。PC 側で共有設定すると、PC のファイルにアクセスできる。こちらの設定は、実際に使っている PC 用のものを参考にする。


次に、lyna で定義されているが、f4750l で定義されていないもの。調べかたには、diff に対して lyra 分を grep し、 "=y" を grep する観点と f4750l 分を grep し、"not set" を grep する観点の 2 つがある。

まずは、lyna で "=y" となっているもの

    CONFIG_JZ4740_LYRA=y
    CONFIG_SOC_JZ4740=y
    CONFIG_KALLSYMS_ALL=y
    CONFIG_FREEZER=y
    CONFIG_PM=y
    CONFIG_PM_SLEEP=y
    CONFIG_SUSPEND=y
    CONFIG_SUSPEND_FREEZER=y

    ここまで 一般的なもの。SUSPEND 関連はコピーする。KILLSYMS_ALL は 勝手に y になった。

      CONFIG_CPU_FREQ_JZ=y
      CONFIG_CPU_FREQ=y
      が無くなっていることに気がついた。

      arch/mips/Kconfig (の Power Management の上) に

      215 +menu "CPU Frequency scaling"
      216 +
      217 +config CPU_FREQ_JZ
      218 + tristate "CPUfreq driver for JZ CPUs"
      219 + depends on JZSOC
      220 + default n
      221 + help
      222 + This enables the CPUfreq driver for JZ CPUs.
      223 +
      224 + If in doubt, say N.
      225 +
      226 +if (CPU_FREQ_JZ)
      227 +source "drivers/cpufreq/Kconfig"
      228 +endif
      229 +
      230 +endmenu

      が入っていなければならない。
      これをいれた上で、
      CONFIG_CPU_FREQ_JZ=y
      CONFIG_CPU_FREQ=y
      CONFIG_CPU_FREQ_TABLE=y
      CONFIG_CPU_FREQ_STAT=y
      CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y
      CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
      CONFIG_CPU_FREQ_GOV_USERSPACE=y
      とする。

    CONFIG_MTD=y
    CONFIG_MTD_CONCAT=y
    CONFIG_MTD_PARTITIONS=y
    CONFIG_MTD_CHAR=y
    CONFIG_MTD_BLKDEVS=y
    CONFIG_MTD_BLOCK=y
    CONFIG_MTD_MAP_BANK_WIDTH_1=y
    CONFIG_MTD_MAP_BANK_WIDTH_2=y
    CONFIG_MTD_MAP_BANK_WIDTH_4=y
    CONFIG_MTD_CFI_I1=y
    CONFIG_MTD_CFI_I2=y
    CONFIG_MTD_BLOCK2MTD=y
    CONFIG_MTD_NAND=y
    CONFIG_MTD_NAND_JZ4740=y
    CONFIG_MTD_NAND_MULTI_PLANE=y
    CONFIG_MTD_HW_RS_ECC=y
    CONFIG_MTD_NAND_IDS=y

    ここまで MTD 関連。Jz4750 用も見た上でいれる。

    CONFIG_INPUT_MOUSEDEV=y
    CONFIG_INPUT_MOUSEDEV_PSAUX=y
    CONFIG_INPUT_EVDEV=y

    PSAUX は入れないが 他は入れておこう。

    CONFIG_RTC_JZ=y
    CONFIG_JZCHAR=y
    CONFIG_JZ_TPANEL_ATA2508=y
    CONFIG_WATCHDOG=y
    CONFIG_JZ_WDT=y
    CONFIG_FB_JZLCD_4730_4740=y
    CONFIG_JZLCD_AUO_A030FL01_V1=y
    CONFIG_I2S_ICODEC=y

    このあたりは JZ4750 も見ていれてみる。

    CONFIG_USB_GADGET_DEBUG_FILES=y
    CONFIG_USB_GADGET_JZ4740=y
    CONFIG_JZ_UDC_HOTPLUG=y
    CONFIG_UDC_USE_LB_CACHE=y

    USB GADGET は入れる。

    CONFIG_EXT3_FS=y
    CONFIG_EXT3_FS_XATTR=y
    CONFIG_JBD=y
    CONFIG_UBIFS_FS_LZO=y
    CONFIG_UBIFS_FS_ZLIB=y
    CONFIG_UBIFS_FS_DEBUG=y
    CONFIG_YAFFS_FS=y
    CONFIG_YAFFS_YAFFS1=y
    CONFIG_YAFFS_YAFFS2=y
    CONFIG_YAFFS_ECC_RS=y
    CONFIG_YAFFS_AUTO_YAFFS2=y
    CONFIG_YAFFS_DISABLE_CHUNK_ERASED_CHECK=y
    CONFIG_YAFFS_SHORT_NAMES_IN_RAM=y
    CONFIG_DEBUG_FS=y

    EXT3 は入れる。UBIFS は モジュールにする。YAFFS2 は入れない -- できるだけ多くのエリア を UBI にする予定で、UBI の上に YAFFS2 は載らない。載るのは一般のFS か UBIFS 。

    CONFIG_REED_SOLOMON=y
    CONFIG_REED_SOLOMON_ENC8=y
    CONFIG_REED_SOLOMON_DEC8=y

    これはなんだろう?


f4750l で not set として出てくるもの。上記を除く。

    # Thu Sep 9 12:49:31 2010
    # CONFIG_JZ4740_LYRA is not set
    # CONFIG_POSIX_MQUEUE is not set
    # CONFIG_TASKSTATS is not set
    # CONFIG_AUDIT is not set

    #
    # Networking options
    #
    (net 関係は 量が多いのでザックリ省略)
    lyra は NET なしらしい。NET なしではちょっと困る。

    # CONFIG_FB_JZ4750_LCD_USE_2LAYER_FRAMEBUFFER is not set
    # CONFIG_FB_JZ4750_TVE is not set
    # CONFIG_FB_JZ4750_SLCD is not set
    # CONFIG_JZ4750_LCD_SAMSUNG_LTP400WQF01 is not set
    # CONFIG_JZ4750_LCD_SAMSUNG_LTP400WQF02 is not set
    # CONFIG_JZ4750_LCD_FOXCONN_PT035TN01 is not set
    # CONFIG_JZ4750_LCD_INNOLUX_PT035TN01_SERIAL is not set
    # CONFIG_JZ4750_LCD_TOPPOLY_TD025THEA7_RGB_DELTA is not set
    # CONFIG_JZ4750_LCD_TOPPOLY_TD043MGEB1 is not set
    # CONFIG_JZ4750_LCD_TRULY_TFTG320240DTSW_18BIT is not set
    # CONFIG_JZ4750_LCD_TRULY_TFT_GG1P0319LTSW_W is not set
    # CONFIG_JZ4750_SLCD_KGM701A3_TFT_SPFD5420A is not set
    # CONFIG_JZ4750D_VGA_DISPLAY is not set

    LCD は、JZ4750 用は別のものとしてあるらしい。後回し。

    # CONFIG_USB_G_SERIAL is not set

    あたらしい USB GADGET 。モジュールで 入れる。
    -- ただ USB GADGET は 1種類しか使えないはず。そうなると G_ETH しか選ばないのだが ...


      USB GADGET には、USB_CDC_COMPOSITE というものがある。

      説明には、CDC Ethernet(ECM) + CDC ACM(serial) の機能だそうだ。昔からあるものは、E_ETH だが、これも CDC Ethernet 。

      CONFIG_USB_CDC_COMPOSITE=m にしといたほうが良さそう。

        ... どうも 複合デバイスを作るためのフレームワークがあるようだ。f_xx.c u_xx.c g_xx.c という風に機能やら何やらを分離しているように見えるし、config.c というのも独立している。



    # CONFIG_CRYPTO_DEFLATE is not set
    # CONFIG_CRYPTO_LZO is not set
    # CONFIG_CRC16 is not set


作ってみた。myconfig-100908.gz

これについてのメモ:

  • CONFIG_JZ_FPGA=y を外し忘れてた。
  • CONFIG_J4750L_NS3K とかボードの定義はしたものの使ってない。-- 出来たら同じバイナリにしたいし削るかも。
  • CONFIG_JZ_UDC_HOTPLUG=y は関数が足りないのでリンクできず外した。
  • CONFIG_KEYBOARD_JZ=y は コンパイルエラーになる。
  • CONFIG_MTD_NAND_MULTI_PLANE=y をしてるのは少数だったので外した。
  • CONFIG_MTD_HW_RS_ECC=y とか ECC 関係はよくわからない。とりあえず JZ4750 の方を参考にして定義した。

    -- HM は Hamming の略、RS は Reed-Solomon の略ということが分かった。そして JZ4750 や JZ4725B は 4/8/12 bit BCH ECC をサポートしており
    CONFIG_MTD_HW_BCC_ECC=y
    CONFIG_MTD_HW_BCC_8BIT=y
    とするのが正しいらしい。
posted by すz at 22:24| Comment(0) | TrackBack(0) | Jz47xx(Linux)

2010年09月08日

オーバクロックとメモリ性能

dingoo A320 で使われているのが、Jz4740。180nm プロセスルールで、仕様では、360MHz。DINGUX では、クロックを変更できて 400MHz 前後まではクロックを上げられるらしい。メモリは、SDRAM 32bit アクセス。SDRAM のクロックは、CPUのクロックの 1/3 が普通で、400MHz なら 133MHz 。

それに対して、Jz4725B は、160nm プロセスルール。 データシートではやはり 360Mhz になっている。メモリは、SDRAM 16bit アクセスしかできない。

前に書いた内容の焼き直しだが、同じクロックの場合、どれぐらい性能的に不利なのか考察してみよう。


    Jz47xx の場合、キャッシュラインのサイズは Iキャッシュ/Dキャッシュ共に 32 バイトなので、通常 32バイト単位での READ/WRITE になる。
     - Linux で CONFIG_MIPS_L1_CACHE_SHIFT=5 という風に設定しているし、32 バイトなのは間違いない。

    そして、Programmers Manual に CPU がどのようなアクセスをするかの記載がある。

      SDRAM は、1,2,4,8-beat の burst アクセスができる。32bit アクセスなら 1 回のアクセスで済むわけだ。16 bit アクセスの場合 たぶん 2 回の 8-beat アクセスをする。ただし、2 回目は 同じ ROW なので少し速い。

      CL=3 だとして、32bit アクセスの場合 32 byte の READ/WRITE は 16/15 クロック。16 bit だと 16 クロック+11/12 クロック。

      • CL=2 の場合、READ -2/WRITE -1 にできる。(同じ ROW なら READ -1/WRITE 0)。 166MHz 品の SDRAM を使っている場合、133MHz CL=2 が可能(な場合が多い)。
        ここは、133MHz CL=2 を前提にする。
      • 32bit アクセスは 14 クロック、16bit アクセスは、25 クロック。


      そうすると 32 bit アクセスの Jz4740 に対して Jz4725B は最大 25/14 = 1.79 -- 1.79倍 遅いことになる。ただし、まったくキャッシュにヒットしない場合の性能差。

        帯域に変換してみよう。133MHz のクロックで ずっと 2バイト読み込めるとすれば、254MB/sec 。32 bit アクセスの場合 254 * 16/14 = 290MB/sec 。16 ビットなら 254 * 16/25 = 163 MB/sec 。

      では、実際はどれぐらい違うのか?

      仮に n% ヒットするとする。

      100 命令実行し キャッシュがヒットした場合 1 クロックで実行できているとする。(100 - n) 個の命令は、メモリアクセスの分待たされるとする。そして、メモリアクセスは、追い出して読み込む動作とする。さらに、SDRAM のクロックは、CPU クロックの 1/3 に設定されているとする(CPU 400MHz に対して SDRAM 133MHz)。

      100% なら 100 クロックで終わるところが...

      32 bit アクセスの場合は、14 * 2 * 3 * (100 - n) クロック 余分に時間がかかる。 16 bit なら 25 * 2 * 3 * (100 - n) クロック。

      n が 99 なら 184:250 。99.9 なら 108.4:115.0。
      n が 90 しかないとすると 940:1600 。

      動画の再生のヒット率は、かなり高いとは思うが、よくは分からない。仮に 90% だとすると Jz4725B は、1.36 倍 遅いことになる。99% なら 1.06倍 。


    さて、最大のクロックは プロセスルールに比例するとする。

    Jz4740 の 180nm に対し Jz4725B は 160nm だから Jz4740 が 400MHz なら Jz4725B は 450 MHz 。1.13 倍 速い。

    速く動かしたいソフトのヒット率が 99% ぐらいなら相殺できそうな感じ。-- でもそううまいこと行くかどうか。

    いろいろ眉唾ものの仮定を入れているので、結論も眉唾だが、必要なデータが揃えば大分分かってくるとは思う。-- ただ、そのときは結果が分かっているはず。上記の考察は結果を分析するとき役にたつ程度だろう。

    他の見方をしてみよう。90% しかヒット率がなければ、32 bit アクセスでも 940 クロックかかる。これが 99% にできると 184 クロックで済む。実に 5.1 倍も速くなるのだ。

      32bit アクセスでも メモリアクセス 1 回が 84 CPU クロック。チューニングに於いては、まずメモリアクセスを減らすのが重要だ。

    さらに言うと十分チューニングされた(動画とかエミュレータ)ソフトなら 90% しかヒット率がないということはないはず。もし、90% だったら オーバクロックに期待するより真っ当にチューニングしたほうが良い。

    ただし、ブラウザとか巨大ソフトは例外。遅くともチューニングしきれないし.. そもそも動かそうとするのが間違っていると考えることにしよう。

    ちょっと動画について考察

      IPU を使うとして、動画のためにどれぐらいのメモリ帯域を使うのだろう?
      640x360 のデータを YCbCr(4:1:1) として 30fps で出力するとする。640x360x30x (4+1+1)/4 = 10MB/sec これは read-write になるから 帯域としては x2 の 20MB/sec 必要。入力は1/10 に圧縮されているとすれば、1MB/sec 。
      で、前のフレームを参照するとすれば、10MB/sec でも読み込む。(こちらはダーティにしないので 帯域も 10MB/sec)
      残りが全部キャッシュに載るはずはないのだが .. ここまでで 31MB/sec 。ちなみに IPU を使って 400x240 R5G6B5 に展開しているとすれば、読み込み 10MB/sec , 書き出し 5.8MB の帯域を脇で使っていることになる。さらに、フレームバッファも 5.8MB/sec で読み込んで 外部に出力している。入力データ 1MB/sec も どこかから読んで DMA で WRITE しているはずなので 足しておこう。
      そうすると CPU の邪魔をしている要因として 22.6 MB/sec の帯域が使われている計算になる。

      ここまでで、使っているメモリ帯域は、53.6 MB/sec 。全部で 163 MB/sec しかないのだから結構な割合だ。

      キャッシュには Iキャッシュもある。16KB しかないから当然足りないのだが、処理ブロック毎にループしているはずで、1 ループで載り切らないことがない限り問題にしなくとも良い。

      あとは、データ。ワークとして使う領域がある。16KB しかないキャッシュに載るとは思えないが、あまり メモリとの出し入れが多いと メモリ帯域を食いつぶしてしまう。さらに カーネルやら サウンド処理やら動いているわけで、余ったメモリ帯域で 動いてくれないといけない。

      ざっと見て相当に厳しそうだ。Jz4755 などは、32bit アクセスで 768p が再生できるとしているので メモリ帯域が足りなくなる とはあまり思わないのだが ... 相当にチューニングしないと Jz4725B で 360p の再生は難しいのではないかと思えてきた。

      もちろん CPU として、能力が足りているかどうか という問題もあるのだが、キャッシュにデータが載らなければ CPU は動けない。メモリのほうも重要なのだ。


posted by すz at 23:46| Comment(0) | TrackBack(0) | Jz47xx(CPU)

2010年09月05日

jz_ubcomm

条件がそろったので、そろそろ Linux の方に手を出していこうと思う。

まずは、ingenic から提供されている Linux をビルドしてみる。

だいぶ前に qi-hardware 経由で 取ったスナップショットだが、

をベースにすることにする。

kernel.org の linux-2.6.31.3 を展開した上に files-2.6.31.3-ingenic-r108.tar.gz を展開して、linux-2.6.31.3-ingenic-r108.patch.gz をパッチすればよかったはず。

次に config 。JZ4725B は、JZ4750L だと思うので、これを y にしている arch/mips/configs/f4750l_deconfig をベースにすることにして .config にコピー。

で、make menuconfig とかして make zImage とかすると なにか出来る。

ただし、f4750l は、評価ボードですらない よく分からない ものみたいなので、ビルドできただけでは 動かない。少しづつ修正していこうと思う。

修正 1) drivers/char/jzchar/Kconfig

JZ4750L だけ仲間はずれなので、追加しておく。

ここまでが準備。本題は コンソールドライバの作成。

USBBOOT に組み込んだプロトコルを使って コンソールの代わりをさせるためのドライバを作成しなくてはならない。

    一から作るのは面倒だからベースとなりそうなドライバを探してみたところ bfin_jtag_comm なんてドライバがあることが分かった。

    まずは、bfin_jtag_comm.c を jz_ubcomm.c にリネームして、drivers/char/jzchar に置く。

    次に namespace だけ 変更。 変更するということは 命名しなくてはならない。"JZ USBBOOT COMMUNICATION CONSOLE DRIVER" ということで ファイル名を jz_ubcomm.c , prefix を ubcomm/UBCOMM にしようと思う。

    で、drivers/char/jzchar の Kconfig と Makefile を bfin_jtag_comm とかを参考にしながら追加。

    一応ビルドできることを確認。


ここまでが第二の準備。形式だけ整ったドライバが出来た。

いよいよ 中身をみて変更していく。

Linux とのインターフェイス

Linux とのインターフェイスには、3 段階ある。ひとつは通常の TTY 。もうひとつは、console としての登録。最後に 初期化完了前の インターフェイス。

ここが最も行数が多い。そして、元のドライバには全部揃っている。

通常の TTY として登録するには、struct tty_driver に必要なものをセットして、tty_register_driver() で登録する。

tty_driver には、関数テーブルもあって、open,close,write,flush_chars,write_room,chars_in_buffer,wait_until_sent といった関数を用意して 登録する。

コンソールとして登録する場合は、struct console に必要なものを セットして register_console() で登録する。必要なものの中には、TTY ドライバも含まれる。

初期化中のメッセージを 表示するには、struct console に 初期化中に使う関数をセットしなければならない。登録の方法は不明。
(作っておくだけでよいような気がするが詳しくは知らない)

基本は、TTY ドライバ。これがちゃんとできれば良さそうな感じ。

bfin_jtag_comm でどのような処理をしているか見てみる。

まず、jtag 経由の通信は、一度に大量のデータを扱うものではないようだ。よく分からないのだが、4 バイトづつデータをおくっている。

4バイトづつでは、大量のメッセージを直接扱えない。一旦バッファリングして、カーネルスレッドで徐々に送り出すようになっている。( 割り込みは使っていない )

USBBOOT では、バッファのサイズを 4KB にしているが もっと大きくもできる。大きなバッファを、USB で一度に 吸いだすようなことは問題ないが、stage2 の関数を定期的に call してやらないと USB の処理自体が止まる。また、ホスト側のプログラムが read してくれないと表示はできない。問題なのは PANIC 。カーネルが止まった後でも ポーリングがされないと USB が動かない。

このあたりの性質の違いを考慮すると

  • console(TTY) への write は、直接 通信エリアのバッファーに追加していくようにして、ローカルなバッファは持たないようにする。
  • カーネルスレッドは利用するが、メインは stage2 関数の ポーリングにする。

こんな感じで処理を作るのが良さそう。たぶんオリジナルよりさらに簡単な処理になるはず。
ただし PANIC 後どうするのか? これは調べないとわからない。

PANIC 処理について:

panic の本体は kern/panic.c

panic したしたあと、panic_notifier_list に登録されている関数を順次 call するようになっている。-- これは 1 回限りなので使いにくい。

あと、panic_blink という 関数ポインタがあり、reboot するまでの間 1msec 間隔で call するようだ。

この関数、誰も使っていないように見える。これを使おう。

とりあえずは、make zImage で、なにか出来た。一応 途中まで動く可能性があり、メッセージが見える可能性があるはじめてのものだ。

だが、成功すればメッセージが出るが、ダメだとなにも起きない。-- これでは デバッグのしようがないのだ。

メッセージが出るまで、デバッグのために使えるのは、LCD のバックライトのみ。

バックライトを使ってどこまで動いたか調べないと。

まずは、起動シーケンスのおさらい

1) zImage の自己解答後の最初のエントリ -- kernel_entry (arch/mips/kernel/head.S)
2) start_kernel (init/main.c)
 3) setup_arch (arch/mips/kernel/setup.c)

setup_arch に来るまで、結構 start_kernel で関数を call している。

さて、backlight を点灯させる関数を作成して、start_kernel の先頭で call するようにしてみた。

... NG 。まだ、マシン依存のコードは動作していないにも係わらず 点灯してくれない。そうなると .. zImage の作り方自体に問題があるのかも知れない。

    まず、zImage は 0x80600000 にロードする。それは正しい。で、zImage が動作すると、decompress_kernel を call して、カーネルを展開する。

    展開アドレスは、vmlinux の 先頭アドレスと同じ 0x80010000 。展開が終わったら vmlinux の開始アドレスである kernel_entry に制御を渡す。

    これだと 0x80010000(offset 64K) - 0x80600000(offset 6M) の間に、カーネルと initrd が入らなければならないという条件になる。そして (展開後の)カーネルのサイズは、4MB +α。なかなか厳しい。

    心配なのは、スタックはどこに取られるのか? stage2 を壊してしまわないかということ。zImage の 展開部分は、スタック用のエリアを配列で持っているから大丈夫。vmlinux 自体も似たようなもので、init_thread_union (arch/mips/kernle/init_task.c) 上に取られる。

    もうひとつ心配なのが、上記の アドレスやサイズが正しく設定されているかどうか。

    zImage のスタートアップでは、

    la a0, __image_begin
    la a1, IMAGESIZE
    la a2, LOADADDR

    という風に ビルド時に定数が埋め込まれる。この値が実際どうなのか というと次のようになっていて正しい。

    -DIMAGESIZE=1792767
    -DKERNEL_ENTRY=0x800144f0
    -DLOADADDR=0x80010000


initrd のサイズを気にする必要はあるが、正しそうだ。

もうひとつ可能性がある。点灯は一旦するが、初期化で消されてしまうケース。(どういうケースはよく分からないが)

とりあえず 点灯後無限ループしてみたところ ... start_kernel の先頭にいれた jz_backlight() で点灯した。

-- とりあえずは、Linux に制御が渡ったので 一安心。

次に setup_arch を call する所まで行くかどうかを試したが.. ダメ。

どこまで動くか jz_backlight() を入れる場所を変更しながら 動かしてみると ..

:
boot_init_stack_canary();

cgroup_init_early();

local_irq_disable();
early_boot_irqs_off();
early_init_irq_lock_class();
-- OK
lock_kernel();
tick_init();
-- OK
boot_cpu_init();
-- NG
page_address_init();
-- NG
printk(....);
setup_arch();



static void __init boot_cpu_init(void)
{
int cpu = smp_processor_id();
/* Mark the boot cpu "present", "online" etc for SMP and UP case */
set_cpu_online(cpu, true);
set_cpu_present(cpu, true);
set_cpu_possible(cpu, true);

boot_cpu_init() は、このようになっている。smp_processor_id()は、0 に展開されている。set_cpu_online() などの関数は、ただの bit 操作。最終的には set_bit() になる。

この程度のものがなぜ動かないのか?

ちょっとここで スナップショットを取っておく。動かないけれども 。


(つづき)
page_address_init() も単に データの初期化で、普通なら 動作するのが期待できるコード。で、次に最初の printk を call している。そうすると既に console の最初の初期化が call されていることになる。

posted by すz at 23:25| Comment(0) | TrackBack(0) | Jz47xx(Linux)

2010年09月02日

P5-5 (PMP3100後継機)

以前 PMP3100 を勢いで買ったのだが、予想に反して Jz4725(無印)だった。

Jz4725(無印) も Jz4725Bも おなじようなものだと思っていたのだが、調べるうちに 全然違うことが分かってきた。Jz4725(無印) は、Jz4740 ファミリーで、Jz4725B は Jz4750 ファミリー。
Port のマッピングが ファミリーで 全然違うので、Jz4725(無印) と Jz4740 は同じカーネルにできる可能性があるが、 Jz4725(無印) と Jz4725B は同じにできない。




そのうち、後継機の P5-5 が FocalPriceから出たので気になっていた。DealExtreme で PMP3100として売られているのも実は P5-5 だと知ったので、ひとつ入手しておくことにした。

    後継機と言っても ハードウェアは、CPU を載せ替えて、ボタン や スイッチなどの印字を 妥当なものに修正しただけに思える。
    -- 最初の PMP3100 は、HOLD, ON/OFF の表示が逆 。あと、2つめの イヤホンジャックに AV-OUT と印字されていた。
    CPU を載せ替えるのは、たぶん入手できなくなったから。
    ファームウェアも前のが動かないし、刷新することになったのだろう。

なにかものを作る場合、だれも持っていなさそうな aneca をターケットにするより 数が出て 安定供給されそうな P5-5 をターゲットにしたほうが良いのだ。

aneca は自分が気に入ったからターゲットにするのだが、気が済んだら P5-5 もターゲットにしたいと思う。

まだ入手しただけだが、Jz4725B なのは確認できた。あとはメモリサイズを一応確認してみる。ついでにメモリが 32MB になったりしてると嬉しい。


    ちょっと USBBOOT で確認

    usbboot :> nquery 0 0
    CPU data: Boot4750
    ID of No.0 device No.0 flash:
    Vendor ID :0xec
    Product ID :0xd5
    Chip ID :0x14
    Page ID :0xb6
    Plane ID :0x74


    4K Page の K9XXG08UXM (2GB) だった。

    次は RAM サイズ。USBBOOT の cfg ファイルに

    BUSWIDTH = 16
    BANKS = 4
    ROWADDR = 13
    COLADDR = 9

    という設定がしてあって

    SDRAM Total size is 32 MB, work in 4 bank and 16 bit mode

    というメッセージがでる。で、この情報を元に CPU の SDRAM 設定をする。CPU は、32MB だと思ってアクセスするわけだが、実際に 16MB しかない場合、データ が 循環する。bank が 上位 2 bit になるので、8MB が実は 4MB + 同じデータの 4MB ということになる。

    W9812G6PH-6 を使っていて 16MB しかないのが明らかな A-41 でまずは確認。

    0x81c00dd4 : 00 00 1c 3c 2c 60 9c 27 21 e0 99 03 d0 ff bd 27
    0x81800dd4 : 00 00 1c 3c 2c 60 9c 27 21 e0 99 03 d0 ff bd 27

    次に A5-5 。... 結果はまったく同じだった。これで RAM 容量は 16MB だと分かった。

    ところで、... 16MB 用のマシン に 64MB の RAM を入れるとどうなるのだろう? OK そうなのだが、A12(pin 18) に配線されているのが条件。PMP3100 だが写真を見ると SDRAM の方に配線されているから 問題ないはず。


よくよく考えると、16MB では DINGUX 並のことはできない。RAM の換装が必須だが 電子工作が趣味ならともかく、普通の人が RAM の換装などできるはずがない。そうすると ターゲットにする意味がなくなってしまう。 -- ただ、このマシンは 裏蓋をあけるとすぐ RAM にアクセスでき、周りにスペースもあるので 換装自体は 最もやりやすい。最初に RAM 換装してみようと 思っているマシンだったりする。

GPIO の 解析


    簡単そうなのが、microSD のセンスと イヤホンのセンスだったので同じことをやってみる。


    初期状態
    PAPIN: 0000ffff
    PBPIN: 823f5f0c
    PCPIN: ffdfdcff
    PDPIN: fd7fffff

    microSD なし PCPIN: ffdfdcff
    microSD あり PCPIN: ffcfdcff
    ありで PC20 が L に変化

    phone1 あり -- 変化なし
    phone2 あり -- 変化なし


    分かったのは、microSD のみ。デフォルトの pullup を落とすとかしないと分からないのだろうか? それとも コントローラ経由?

    さて PC10 からの PWM は 110111 (MSB が PC15)のビット列。
    これを見るとバックライトは、PC13/PWM3/UART-RxD のように思える。
    実際やってみると当たり。-- まぁこれは 選択枝がないようなもの。... それはともかく、コントーラの制御に UART を使っているものとばかり思っていたのだが違うのかも知れない。


すぐわかるのはここまで。他はどうしよう。

    課題1 PHONE1/PHONE2 のセンス

    Linux が動いてからでも遅くない。とりあえずパス。

    課題2 ボタンの制御

    これはどうやったら分かるのだろう? 配線もわからなければ、制御するための プロトコルも分からない。

    こういうのに近いものがあるとすれば ... A-330 のワイヤレスコントローラか。受信部にマイクロコントローラが付いているところから よく知られているコントローラ互換のように思えるのだが ...

    ロジアナ使うにしても できることは、コントローラ自体の PIN の変化が分かるだけ。分析すれば どのように制御しているかは分かるだろう。で、GPIO がどう配線されているかを見つけるのはどうしよう。... テスターで頑張ればなんとかなるか。

    課題3 スピーカー出力切り替え

    これも 後回しで問題ない。

    課題4 PHONE の ポップノイズ対策 (ないと思うがあるかも知れない)

    課題5 LCD の制御

    LCD のつなぎ方は、割と決まっている。特に 2.8 inch なら A-320 などと 同じはず。-- と思ったが、A-320 の 新しいタイプ ILI9331 は SLCD(SmartLCD: HSYNC/VSYNC を使わない) 接続だそうだ。

    確かめてみることはできるだろう。DINGUX の hwinit を参考にすれば 良さそうだ。... ソースコードの情報は、dingoo-linux の ここ。svn でダウンロードできる。


    課題6 MicroSD の CS

    MSC1 は、CLK/CMD/D0 のみ。CS は GPIO でやることになっているようだ。そうすると PIN を見つけないと MicroSD が使えない。

    これは基本機能なので重要だ。なんとか見つけないと。... と思ったのだが、どうも SPI モードとは違うらしく 上記の線だけで良いのかも。


付録 PMP3100(旧機種) の基板写真


P5-5 JZ4725B ピンアサイン表 (作成中)

凡例 : x 割り当てに選択の余地がないピン
o A-41 固有の割り当てで判明したピン
? 不明なピン

Jz4725B

? 2 PD18 LCD_PCK(LCD)

? 48 PC15 PWM5

? 54 PC20 WAIT(SRAM)
? 55 PC22 CS2/MSC0_D3

o 57 PC13 PWM3/UART0_RxD(UART)
o 58 PC12 PWM2/UART0_TxD(UART) T1
? 59 PC11 PWM1/I2C_SCK(I2C)
? 60 PC10 PWM0/I2C_SDA(I2C)

? 68 ADIN1

x 84 PPRST(RTC)
o 85 PB31 WKUP(RTC)
x 86 PWRON(RTC)

x 100 BOOT_SEL0
x 101 BOOT_SEL1
? 102 PD23 LCD_SPL(LCD)
? 103 PD22 LCD_CLS(LCD)

? 105 PD25 LCD_REV(LCD)

? 107 PD24 LCD_PS(LCD)
x 108 PD20 LCD_VSYNC(LCD)
x 109 PD19 LCD_HSYNC(LCD)
? 110 PD18 LCD_DE(LCD)
? 111 PD17 LCD_D17(LCD)
? 112 PD16 LCD_D16(LCD)



P5-5 JZ4725B 判明ピン
バックライト:
o 57 PC13 PWM3/UART0_RxD(UART) H で ON
microSD センス:
o 54 PC20 WAIT(SRAM) L で microSD あり


JZ4725B 調査対象ピン

制御候補

? 48 PC15 PWM5/A18(SRAM)

専用機能
? 57 PC13 PWM3/UART0_RxD(UART)
? 58 PC12 PWM2/UART0_TxD(UART)
? 59 PC11 PWM1/I2C_SCK(I2C)
? 60 PC10 PWM0/I2C_SDA(I2C)
? 68 ADIN1

電源制御
x 84 PPRST(RTC)
x 85 PB31 WKUP(RTC)
x 86 PWRON(RTC)

GPIO 候補
? 54 PC20 WAIT(SRAM)
? 102 PD23 LCD_SPL(LCD)
? 103 PD22 LCD_CLS(LCD)
? 105 PD25 LCD_REV(LCD)
? 107 PD24 LCD_PS(LCD)
? 111 PD17 LCD_D17(LCD)
? 112 PD16 LCD_D16(LCD)
+ UART ?
posted by すz at 01:30| Comment(0) | TrackBack(0) | Jz47xx(機種解析)

aneca A-33

またもや買ってしまった。





今度は、aneca A-33 -- FocalPrice だと 37.80 ドル

実際に買ったところは、everbuying で もうちょっと安い 33.93 ドル。-- まぁ有名でないし勧められるかどうかわからないので、ForcalPrice の方を先に紹介しておく。

追記 10/10/15: everbuying は売り切れた。

    2-3 回利用してみたが、対応は悪くない。ただ 品切れになったから姉妹ショップから買えとか変なことを言ってきたりする。安いのも B級品とかで 品質が悪いのかも知れない。
    あと、受け取りまで やたら時間がかかる。20 日以上が普通で FocalPrice よりひどいかも。

33.93 ドルだと 87 円換算で 3000円を切るレベルの値段。これで 16:9 400x240 のディスプレイと FLASH 4GB のモデルが手に入る。

ただ、これは FM ラジオもスピーカーも付いていないようだ。で、なぜかストップウォッチが付いている。

    使わないものは、ないほうがスッキリする。ただ FM ラジオのパターンは線を引き出すために付いていて欲しい。-- taobao で売っているのには、FM が付いているからパターンはあるようだ。ちなみに、バッテリーは 600mAH だそうだ。

ボタンは、サイドに 5 つと、液晶面に 1 つ。A-41 より 1 つ多い。

電源スイッチも反対側のサイドに付いている。たぶん例によってハードスイッチ。-- 開発するには、ソフトで電源を切るタイプ(A-320 など)より便利。

A-41 と同じ背景だし おなじ Jz4725B なのだろう。メモリは 16MB のはず。(PMP 機能だけならそれ以上は積まないだろう)

aneca でのファームウェアはカスタマイズのレベルが高かった。これも同じはず。

    ひどい日本語が修正されているし、カレンダーもまとも。
    フォントのサイズも変更されてて、ちゃんと見栄え良く画面に収めるようにしている。
    あと SJIS で埋め込んだ ID3タグがちゃんと表示されるし、EBOOK も UTF-8 なら表示される。(.. これは P5-5 でも OK だからFWのベースに入っているのだろう)
    メニューもなにか増えている。ロックができたりするし。

H.264 は無理だが xvid 程度の動画を見たり、mp3 を聞くなら実用として使っても便利そう。

改造とかの面でいうと、スイッチの配置からみて ボードはたぶん 筐体 の半分ぐらいで 取り出した場合コンパクトで良さそう。あと、液晶面のスイッチの周りになにか仕込むスペースがありそう。

... というわけで A-41 より気に入りそうな感じ。

こんな感じで、気に入りそうだとすぐ買ってしまっている。そのかわり Andoid とか Arduno(電子工作むけのボード)は、買わないのだ。これでよいのだ。(実は Android は1つ購入。だが、当面これだけの予定)

追記:入手できた。

大きさは、縦 9.8cm 幅 5.1cm 厚さ 1.0cm 。

    ちょっと iphone とかのサイズ比較。(ケースが使えるかの判断用)
     iphone4 : 115.2 mm x 58.6 mm x 9.3 mm
     ipod touch2 : 110mm x 61.8 mm x 8.5 mm
     ipod touch4 : 110mm x 58.9 mm x 7.2 mm

スイッチは左サイド 下 に電源スイッチ(スライドSW) 。右サイドに +/- , ←/→ , PLAY/PAUSE の 5 個。と液晶面 下に 1つ (M)。ケースはプラスチック。サイドは メッキしたプラスチック。

まずは、機能の確認。A-41 とまったく同じ。ストップウォッチなどないし、スピーカも付いている。電源スイッチも同じでただちに電源OFF にできる。あと気がついたのだが PLAY/PAUSE ボタンの長押しでシャットダウンする。そして、その状態から PLAY/PAUSE ボタンで電源ON する。

CPU は、予想どおり JZ4725B 。Mと書いてある 液晶面のボタンを押しながらUSBに挿すことで USBBOOT になる。


ケースはプラスチックで嵌め合わせ。精度は良さそうなのだが、なぜかサイドに隙間がある。おかげで分解は簡単で、裏蓋が簡単に外れた。



見ると バッテリーは 650mAH で A-41 と同じものが使われている。

(拡大)

基板は、A-41 より少し大きい感じ。スピーカーのところが U字型に切り抜かれている。FM ラジオモジュール用のパターンもある。あと、メモリは 16MB。

製造は、2010/8月 って 最近なのか。あ、下のコイルが欠けている。(よくあることだが、ちと残念)。メモリは、W9812G6PH-6 で FLASH は、29F32G08CBAAA とマーク (Micron MT29F32G08 ?)。

    メモリを換装するには、基板をはずさないといけない。ネジが 2 つあるのでそれを外すのか? 液晶を含めまるごと外れるような気がするのだが ...

    ここから先の分解は、ちょっと慎重にならないとマズそう。液晶のところを見たいのだが ... 今回はパス。

    ちなみに、もうひとつの方も裏蓋を開けているのだが、やはり 2010/8 月。箱が違ったので 1つは古いと思ったのだが違った。

    あとで気がついたのだが、簡単とか言いながら 裏から見て 左中央のツメを折ってしまっている。-- 破片が見つからないし、スキマがあったのはこれが原因かも知れず、最初からだったかも。あと、microSD が入っているとひっかかって裏蓋をはずせない。すぐ忘れてやってしまうので要注意。

A-41 と同じような感じ。回路的にもほぼ同じなのだろう。解析は楽そうだ。

満充電になると、充電のアニメーションが止まることに気がついた。充電中に電圧を測定しても満充電かどうか分からないはずなので、充電IC の 状態をセンスするために GPIO が割り当てられているはず。

    A-41 も調べてみたが、どうも同じようだ。PLAY/PAUSE ボタンでの 電源 ON/OFF も同じだった。-- そういえば WKUP ピンが割り当てられているのだった。 WKUP は、サスペンド/ハイバネーションからの復帰ができる。ハイバネーションといっても 状態をセーブしてなけれれば電源ON と同じ。

    この電源 ON/OFF 機能を知らなかったのだが、P5-5 も同じだった。Neo Slim 3000 にも 機能は付いていた。(OFF はできるが ON でハングアップする)。ボタンは、P5-5 が SELECT の位置 (電源マークあり) 。Neo Slim 3000 は L ボタン(これも電源マーク)

    それはともかく、普段は PLAY/PAUSE ボタンで 電源 ON/OFF するようにしていれば、アラーム機能も付けられるわけか。
    (ちなみに、ハイバネーションは電源 OFF と大差ないから消費電力は気にしなくて良い)

少々使ってみた。液晶は 3inch 432x240 。視野角は予想より狭い。
H.264 の 動画の再生は 400x226@30fps でも音ズレするのだが、動きが少ない場面ではちゃんと再生できている。640x360@24fps も見てみたが、明らかに遅くスローモーションのようになる。どうもフレームスキップはしてないようだ。

    Jz47xx は、SIMD 命令(XMU) を使ったソフトコーディック。いままで買った JZ4725B の挙動は全部同じなので コードが共通なのだろう。Jz47xx の潜在能力はもう少しあると思えるので、自作ソフトが動かせるようになったらチューニングしてみたい。
    あと、オーバークロックもしてみたい。180nm プロセスのJz4740 は 400MHz+αで動作するようだが、Jz4725B は、160nm でオーバークロック耐性が高いはず。400 x 180/160 = 450 なので 450MHz+α で動くかも知れない。

不具合はちょっとある。USB の接触が悪く。接続が切れたりする。これは、使っているうちに良くなるかも。

実は 2 つ買ったのだが、1 つはいくら充電しても 充電が進まないことが判った。バッテリーには過放電保護が付いているようだし 膨らんでもいないので、劣化が理由ではないかも知れない。-- 充電回路が変なのか?

    一晩充電したら、充電完了した。バッテリーが弱っていて予備充電状態が長かったのかも。

    追記: 接触は問題ないようだ。バッテリーも弱っている感じではない。

もうひとつ気になることがある。電源SW OFFで接続すると バックライトがチラつく。電源SW ON にすると それが収まる。この現象は両方で起きる。

電源スイッチが入っていると バッテリーからも電源供給するような回路でも入っているのだろうか?

    バックライトがちらつくのは、バッテリーの残量低下でも起きた。どうも 4 つあるうちの 1つ 2つが、電圧が低下すると消えるようだ。ちなみにバックライトは 並列で 昇圧回路は入っていないため、電圧の影響をうけやすい。

所感:

  • 基本は、A-41 と同じだが、表示できる面積と情報量が多い。Linux を動かす前提なら、情報量が多い方が嬉しい。
  • Bluetooth を付けてみたい。その前提ならプラケースの方が加工も楽だし、電波を通すし都合が良い。ケースは嵌めるだけなので、スライドさせる A-41 より 加工の自由度が高そう。

    ちなみに、デバイスを付けるとしても I2C しか I/O がない。シリアルさえ使えない。Bluetooth を付けるにも スレーブコントローラが必要。 こういうものでも、司令塔にはなれるので、ロボットとかの 制御に使えるかもしれない。
  • オーバクロックの面では、A-41 も A-33 も CPU の上の空間は空いている。P5-5 は バッテリーがあり、Neo Slim 3000 はすぐ LCD。SDRAM に関しても同じ。アルミケースの A-41 の方が放熱はしやすいが、A-33 も ケースに穴を空けてしまえば ヒートシンクさえ付けられるので 問題ない。
  • LCD の視野角が狭いのが残念。まぁ無理を言っても仕方ないし ..

    しばらく使って..

  • A-41 と比べてみたら低音が出ていないし、同じボリュームでも音が小さめ。-- カップリングコンデンサが 47uF になってたりしている。

  • メニューの移動で音が聞こえる。電源が弱いようだ。(A-41 は聞こえない)

  • A-41 は、持ち歩くとき ボタンを誤って押してしまうことが結構あったのだが、これはボタンがサイドだからかあまりない。

    サウンドは問題あるが、こちらのほうが使い勝手が良いようだ。

これと A-41 を本命として Linux の移植をしていきたい。

    換装用 メモリは、32MB 多数 と 64MB 2 個を確保。

    Linux を動かすマシンは 32MB 以上にするつもり。

    64MB は 開発に使うマシン優先。ひとつは、A-41 にしたい。

    -- 64MB は消費電流が大きいうえに、133MHz で クロックアップ耐性が低い。メモリが足りるなら 32MB にしたい。

さて、そろそろ簡単なところを解析.

NAND FLASH :


usbboot :> nquery 0 0
CPU data: Boot4750
ID of No.0 device No.0 flash:
Vendor ID :0x2c
Product ID :0xd7
Chip ID :0x94
Page ID :0x3e
Plane ID :0x84


Page ID から 消去ブロック 512KB / ページサイズ 4KB 。
Plane ID から 16Gb プレーン x 2 = 4GB 。

ということが分かる。

バックライト は、PC13 (PWM3) で A-41 と同じだった。
あと、MENU と PLAY/PAUSE 以外の ボタンのどれを押しても PD17 が L になるのも、A-41 と同じ。


    default:
    PAPIN: 00008f83
    PBPIN: 823f7b3c
    PCPIN: ffdfdcff
    PDPIN: ffffffff

    M button:
    PDPIN: ffffffff (not pressed)
    PDPIN: ffdfffff (pressed)

    PLAY/PAUSE button:
    PBPIN: 823f7b3c (not pressed)
    PBPIN: 023f7f3c (pressed)

    MicroSD
    PCPIN: ffdfdcff (not inserted)
    PCPIN: ffcfdcff (inserted)


    A-33 JZ4725B 判明ピン
    バックライト:
    o 57 PC13 PWM3/UART0_RxD(UART) H で ON (A-41 と同じ)
    microSD センス:
    o 54 PC20 WAIT(SRAM) L で microSD あり (A-41 と同じ)
    ボタン MENU "M" :
    o PD21 LCD_DE(LCD) 押し下げで L (A-41 と同じ)
    ボタン PLAY/PAUSE "⇒II" :
    PB31 WKUP(RTC) 押し下げで L (A-41 と同じ)
    スピーカーAMP :
    PD18 LCD_DE(LCD)
    LCD : ILI9326 16bit SmartLCD 接続
      LCD RESET : PD23 LCD_SPL(LCD) (A-41 と同じ)
      LCD CS : PD22 LCD_CLS(LCD) (A-41 と同じ)

    要調査:
  • PHONE センス
    -- A-41 にはあったが、見つからない。なしでも実装できるようだからないのかも。
    カップリングコンデンサは、J476 になっている。周りの抵抗は 470 x2 と 330 x 2 。よく分からないものの 小容量 コンデンサ を使えるようにするための抵抗 と MIX 用?

      A-41 と同じイヤホンで比べてみたのだが、明らかに低音が出ていない。47uF ではダメで最低 100uF でないと。-- いずれ付け替えるつもり。

      あと、電源も弱いようだ。メニューを移動したとき、CPU が動作する音が聞こえる。-- まるで一昔前のパソコン。A-41 は聞こえない。

  • スピーカースイッチ
  • 満充電センス
    -- 存在しそうなことは分かった。しばらく使って GPIO の差分を見てみる。→ GPIO には変化なし -- 違うのか?
  • microSD CS (不要)
    -- Programming Manual に 1bit モードの記述がある .. ドライバもサポートしている(CONFIG_JZ4750_MSC1_BUS_1)。GPIO はどうも HOTPLUG_PIN (上記 MicroSD センス)のみを使うようだ。
  • スイッチセンス (+/ー/←/→ ) (PD17 - ADC?)
    -- ADC が使えるのは、Linux が動いた後なので解析は先延ばし。
  • LCDの接続。
    -- 接続自体は済みなので不要といえば不要。HSYNC/VSYNC を使う接続(Normal LCD)なら 初期化の方法だけ分かれば良い。コントローラを使う SLCD の接続(Smart LCD)なら コントローラの詳細を知る必要がある。

    追記:Smart LCD 接続。コントローラも判明。432x240 の ILI2326 。
    CS/RESET は、GPIO を使うが
     LCD RESET = 102 PD23 LCD_SPL(LCD)
     LCD CS = 103 PD22 LCD_CLS(LCD)
    だということが分かった。(A-41 も 同じピン割り当て)


追記:再度分解

液晶の接続を見るために再度分解した。

やはりネジは外す必要があった。あと、LCD の一部が弱く接着されていた。それ以外に固定しているものはなかった。




これは、全部を外したあとのケース。どうなっているか記録。



液晶は、0.8mm ピッチ 40 pin だった。HUARUI T-0052-B というものらしい。-- なんか NC が多い。
コンデンサ(CXX)やダイオード(DX) ばかりで抵抗がない。
バス幅などの設定はないようだ。
写真をじっくりみると、線が集中しているところ(8-30)、18pin 分と 7pin 分に分類できかも。-- 上の接続部分を見ると、そこで間がある 。通常 液晶の接続部は、COG の LSI と 1:1 に対応している。間があるということは、信号的にも分類が変わるかも知れない。要するに 18pin 分が DB0-17 ではないか?
それはともかく、LSI 上の配列と信号の配列には相関性がある。ILI9325/ILI9326 ともに LSI の配列は、

RESET
VSYNC
HSYNC
DOTCLK
DEN (0: enable RGB interface )
Data bus (DB17-DB0)
RD
WR
RS
CS

の順で並んでいる。A-41 のコネクタもこの順。おそらく A-33 も順番だけは、これとほぼ同じはず。

いくつか分かったのでメモ

1 o NC (YU)
2 o NC (XL)
3 o NC (YD)
4 o NC (XR)
5 o GND
6 (RESET ?)
7 o NC
8 (CS?)
9 (RS?)
10 VCC ?
11 (WR?)
12 (RD?)
13 o GND (DB0?)
14-21 DB1-8?
22 o GND (DB9?)
23-30 DB10-17?
31 ?
32 o NC → GND
33 NC
34 ?
35 o GND
36 o LED-A
37 o LED-K → GND
38 o LED-K → GND
39 o LED-K → GND
40 o LED-K → GND


  • HSYNC/VSYNC/DOTCLK/DEN を入れるには信号線が足りない。
  • GND に接続されているピンの関係から DB1-8,DB10-17 の位置を推測した。上記の順と逆順なら、8-12 に CS/RS/WR/RD の順で配置されていそう。そうなると 31-34 のあたりは、LCD によっては、DEN/DOTCLK/HSYNC/VSYNC が配置されているのかも。
  • ILI9326 とか ILI系なのは間違いなさそうだ。あとは、6,8-12,14-21 をロジアナで調べればはっきりするはず。



    これはボタンのところ。一応記録。ボタンに関係するものは、2-3 個のように思えるのに沢山載っている。よく見ると Power 系のデバイス -- 大きなコンデンサや ダイオード 三端子のなにかがある。



    再組み立てに失敗。液晶がずれた。そういえば、ネジもつけ忘れた。で、やり直してみたが、似たような感じになってしまった。

    -- SDRAM をつけたら真面目に組むことにして 当面このままにしよう。
    -- 全部はばらしていないもうひとつの方も 左と下が 1mm ほどずれている。よくよく考えれば、基板を固定すれば LCD の位置はほとんど変えられない。もともとだったとして納得しよう。

    追記:写真集(1号機)

    いくつかパーツを外している。(12MHz Xtal , スピーカアンプ横コンデンサ , カップリングコンデンサ, スピーカー, バッテリー , LCD)

      現在不動状態
    • 写真を取るために、ホットボンドを剥がしたりしていたら、クリスタルの足がもげてしまった。小型の 12MHz の水晶はどこにも売っていなくて焦ったが、使わなくなったカードリーダに入っていた。
    • スピーカーアンプ横コンデンサも 清掃でもげてしまった。
    • それ以外に、32.768 kHz 水晶のランドが剥離。となりの 10MΩ(106) に付けている。
    • (判らないが)スピーカー 用の端子も剥離しかけ。(ハンダ吸い取り線でやってしまった。)
    • カップリングコンデンサは交換途中。
    • 動かないので、LCD を剥がしてしまった。ちょっと乱暴にやったのとハンダ吸い取り線での清掃で、LCD の端子も 剥離しかけがいくつかある。

      動いても LCD を付けないで、調査用にするつもり。
       - 予備を発注 (3,4号機)












    ランド剥離したところについてのメモ


      この 2カ所だが、スピーカーアンプのところは 完全には剥離していない。今後 スピーカを使うつもりもないのだが 一応 瞬間接着剤かなにかで貼りつけておこうと思う。
      問題は 32.768 kHz 水晶。どうも CPU との間を切ってしまっているように見える。

      CPU の 水晶の PIN は、この写真の 右の方 -- ランドしか見えていないピン(81:RTCLK) その左どなり(82:RTCLKO)。

      コンデンサは、106 の下と 左上の白いやつ。CPUから来た線が、 上のコンデンサ,水晶,106(の左端子) に分かれるところを剥がしてしまったらしい。ちなみに 下のコンデンサは、水晶の足と106 と接続した上で 右の抵抗(222)を通して CPU(82:RTCLKO)に接続されている。


    追記:写真集(2号機)




    2号機 も改造した。内容は、バッテリーを外してコネクタを付け、ケース側に 別のバッテリーを接続するというもの。スピーカーも外している。

    • 注意! 中華バッテリー自体危険なものであり、改造はさらに危険な行為。十分な知識とリスクの覚悟がなければ 扱ってはいけない。
       参考:別記事「中華バッテリーについて」

    • 付けたバッテリーは、BC50 (750mAH , $2.46) 2 個並列。

        BC70 (1000mAH, $3.13) というのもある。厚みが 4mm → 6mm と増えるが 底面は同じサイズ(45mm x 37mm) のようだ。
        BC50/BC70 は、端子が横方向なので、ニコイチで向かい合わせることができて都合が良い。

      並列と言っても、保護回路を外して生のバッテリーにした上で、並列にし、別の保護回路を付けている。
       - 別の保護回路にしているのは、元の保護回路は、他の中華バッテリーと違うので信用できないと思ったから。
        実際やばいようだ。
       - わざわざこうやって並列にしているのは、むき出しにしたケース間の電位差をなくすため。ただし、ケースは (+) 側なので、結局絶縁が必要。
       - 工作する際は、ショートに気を付けている。とくに生のバッテリーがショートすると超危険(燃えたり、爆発さえする恐れあり)。
       - 並列にする際には、 抵抗で一回接続して、電圧が同じにしている。
       - 容量が 1500mAH になった計算だが、本当に それぐらいありそう。起動しっぱなし (アイドル、LCD OFF) で 36H ぐらいもった。

    • 青緑なのは、0.3mm 厚 SMDプロトタイピング基板 (100円)
       - 合わせ目を隠す + バッテリーのガードが目的。

    • 金色なのは、ポリミドテープ ($2.19)
       - 絶縁と バッテリーの汚れ(のりで汚い)を隠すのが目的。

    • ケーブルは、スピーカー用の穴を広げて そこから内部に配線。

    • ケースにバッテリーを付けたのは、内部に回路を仕込めるスペースを確保する目的もある。

    • 出来上がりの サイズを見ると 底面が 45mm x 80mm -- A-44 にも合うようにできそう。今度は、BC70 で試してみよう。 (買えなかったし、やばそうな気もするのでパス)

    • 電圧を調べてみた。
       - シャットダウン 3.44V
       - 満充電 4.17V
      ちゃんと制御できているようだ。
    • 動画再生時間 は、(明るさ 4で) 6 時間ちょっと。
    • 時計が出ている画面で backlight ON (明るさ 4) だと 9時間30分 (+α)

      • LED Off だと 36H で ON だと 9.5H 。実際に 1500mAH とすると、Off 42mA / On 158mA で 差が 116mA もある。昇圧はしておらず 4 個なので LED は たぶん 60mA ぐらい。
      • フル稼働だと 6.3H として 238mA 。LED ON からの 増加は 80mA 。

        適当な計算だが、目安にはなるとおもう。

  • posted by すz at 01:02| Comment(0) | TrackBack(0) | Jz47xx(機種解析)