2010年10月19日

Jz4755(T552とか)

いままで、JZ4725B の話題ばかりだったので、ここで JZ4755 の話題をまとめておこうと思う。

CPU について




0.4mm ピッチ LQFP176 pin パッケージで、内部のブロック図はこんな風になっている。

JZ4725B とこが違うのかというと...

  • SIMD2 :

    SIMD 命令は JZ4725B にもある(60命令)が、命令が追加されているらしい。(SIMD2: 114命令)

  • SDRAM :

    JZ4725B は 16bit 幅だが、16bit/32bit 幅を選択できる。

  • MSC1(SD/MMC インターフェイス):

    JZ4725B は、1bit データ幅 で SD/MMC の性能を使い切れない。JZ4755 は 4bit データ幅。
    ちなみに、SDHC の最高周波数は 50MHz だが 80MHz まで使える (SDHC UHS-I対応?) 。
    MSC0 というのもある。(JZ4725B も同等機能 , 4bit 最大80MHz) ... のだが NAND FLASH と排他で使うもので boot 用。

  • SPI/SSI インターフェイス(最大 50MHz):

    JZ4725B にはない。MSC1 とピンが共用なので実質使えないかも。

  • タッチパネルインターフェイス:

    JZ4725B にはないが、その他の Jz47xx チップはたいがい持っている。

  • UART :

    JZ4725B と同等の 1ch だが、JZ4725B は GPIO に使われてしまうケースが結構ある。JZ4755 は実質使える。

  • サウンド出力 (カップリングコンデンサレス) :

    よくわからないが、BTL 出力ができるらしい。JZ4725B には BTL はない。

  • CS2/CS3 :

    NAND FLASH/SRAM の チップセレクト 要するに NAND FLASH/SRAM を合計 4 つまで付けられる。JZ4725B は 2 つまで。

  • AC97/I2C 出力: JZ4725B にはない。
  • カメラ入力: JZ4725B にはない。
  • TV 出力: JZ4725B にはない。
  • TS インターフェイス: JZ4725B にはない。


Jz4755 のチップは taobao で買える。たとえば ここなら 1 個あたり 25 元 (1元=15.5円として 390円)。パッケージは、0.4mm ピッチとはいえ LQFP176 で 個人の電子工作で扱える範囲には入る。
 あと こことか。

    DINGOO A320 などで使われている JZ4740 は BGA で、電子工作でどうにもできないので、あまり興味がなかったりする。

    JZ4760 には興味があるが、LQFP176 あたりの PMP向けチップが出た上で買えるようにならないと。

さて、このチップは、Dual-Core だが、1 つは VPU で DSP 的に使う。キャッシュのかわりに SRAM が 32KB 。-- どうやって そのもうひとつを使うのか分からないのだが、どうも qi-hardware のメーリングリストに入って ある人にリクエストすれば NDA なしでもらえるらしい。

    qi-hardware が入手しているドキュメントには、

    • XBurst Microprocessor Core, Rev 1.0, Apr 2007, 62 pages
    • Jz4725B Data Sheet, Rel July 7, 2009, 37 pages
    • Jz4725B Programming Manual, Julz 14, 2009, 529 pages
    • Jz4720 Data Sheet, Rev 1, Jun 2008, 37 pages
    • Jz4740 Data Sheet, Jun 2007, 35 pages
    • Jz4740 Programming Manual, July 22, 2009, 539 pages
    • Jz4750 Data Sheet, Apr 2009, 40 pages
    • Jz4750L Data Sheet, July 17, 2009, 37 pages
    • Jz4750L Programming Manual, July 14, 2009, 570 pages
    • Jz4755 Data Sheet, July 7, 2009, 33 pages
    • Jz4755 Programming Manual, Jul 22, 2009, 732 pages

    というのがあるそうだ。この情報は、google のキャッシュに残っていたもの。Jz4750L 単独で Data Sheet やら Programming Manual があるのが興味深いが、それはさておき Programming Manual がないと VPU は扱えなさそう。

    そもそも、Jz4725B の Programming Manual ですら入手できていない。Linux のソースコードがあるので、たいがいの機能は使えるわけだが、VPU は どういう使い方をするのか 分からない.. と思う。

      追記: なんと jz4755_pm が入手できた。VPU が出来ることは、IDCT, Motion Compensation,Motion Estimation,De-Block の 4つだけで レジスタに値を書き込むことで制御する。

    ところで、Jx4755 とかの Xburst core は、MIPS32 4K core あたりとだいたい互換らしいのだが、4K core (5段パイプライン)だと 180nm プロセスで 167MHz ぐらい。Xburst(8段) は同じ 180nm プロセスで 360MHz まで行っている。なにげに結構すごいのかも。

Jz4755 が載った PMP -- Mahdi T552


今は Jz4725B の PMP ばかり集めていて Jz4755 が載った PMP は持っていない。Jz4725B が自由に扱えるまで手を出さないつもりだが、一応調べてみた。

このなかで、Mahdiが結構 Jz4755 の製品を出している

そのなかでも気に入ったのは、T552



こんなやつ。4.0 inch (480x274) 。

気に入ったのは、ここのレビューに分解写真があるのも理由。





  • メモリは、W9812G6GH-6(16MB) x 2 。
  • 例によって FM ラジオのパターンもある。
  • LCD は 0.5mm ピッチ 50pin ? -- RGB インターフェイスか?
  • 裏面に部品がほぼないのは、嬉しかったり。

面白いことに KO Digital HD-300 というのも同じ筐体のようだ。



これは一体なんなのだろう? ProjectXA の文字が見えるところから、ChipRise というところが設計・製造しているのだろう。.. ということは、両方 OEM ?

    KO Digital (可欧) というところも 大きなメーカーっぽい。http://www.kocode.com (FLASH / サウンド付き注意)
    HD-300 はだいぶ古い製品のようで現行は、HD900A とか。ここ見ると 明らかに Jz4755 。画面が例のもの + 720p対応。
    ... どうもよくわからないが、HD系は Jz4755 が多そう。(ただし HD800系は RK かも)


それはさておき、これはどこで買えるのだろう?

ひとつは、ownta.com で、$79.80 -- 84円換算で 6700円。
Free shipping だが、 Registered Airmail $15.74 というのを見ると不安になる。送料を払うなら Express Shipping (3-5 days) - $16.74 が良さそう。

もうひとつは、taobao で、例えば ここここだと 送料込まずで 265元 -- 15.5 円換算で 4100 円。
随分と安いように見えるが、代行業者を通さないと買うのは無理そう。

    例えば taobao 代行業者の グッズエイト を通すと ...
     ( 265元 + 中国国内送料 約20元 + EMS送料 60元 ) x 15.5(元→円)
       + 手数料 500円 = 約 5800円。( これ以外に +振込料金x2回 )。

    代行業者にもいろいろあって、上記は一例。利用したこともないし別にお薦めというわけではない。
    だいたい 元→円のレートは、12円ちょっと。明示されている手数料は 5% だが、レートが 30% 増しに近い。そしてそれは、手数料や送料にもかかる。それでも高くなければ良いのだが、なにか釈然としない。


まぁこんな感じなのだが、 T552 だと Camera インターフェイスもタッチパネルも使っておらず .. 線も引き出せない。(自分でビルドした Linux を動かす前提で VPU が使えないとすると) Jz4725B の PMP と比べて メモリと SD/microSD が速いだけで 機能的にはあまり変わらないことになる。

これではちょっと面白くないのだ。... というわけでパス。

追加: T555




T552 が高いのは、液晶のせいで Jz4755 が高いせいではない。たとえば ここの T555 は、3.0 inch 400x240 , 4GB で A-32 の Jz4755 版という感じだが、170元(本体のみなら 150元)しかしない。... ただ 小さいのはメモリも 16bit かも知れないし、やはり T552 のほうが良さそう。
 あと ここ は、180元。

追記:
パスと書いたが、Jz4755 の Programmers Manual 手に入ったし、買ってしまうことにした。

なにを買うかだが、T552 は、まず欲しい。理由は Jz4755 で 本当にちゃんと H.264 が見れるのかどうかを チェックするため。ちゃんと見れるのならば、画面も大きめだし 実用としても使えそうだ。

ただ、プログラムを動かしたりするのならば、LCD がネック。Smart LCD ではないと思うので制御がたいへん。電子工作で LCD を 外すとかするなら 0.5mm ピッチ 50 pin なのは 嬉しい。フレキとかコネクタの入手性は、54pin の Neo Slim 3000 より良い。

T555 も良いように思えてきた。たぶん Smart LCD で デバッグとかするのに都合が良いし、電子工作で使うにしても LCD を外して線を引き出すのは 楽なはず。ただし、メモリが 32bit でない可能性が高く その点ではイマイチかも知れない。 jz4755 でないということはないはず。720p 対応を謳っているし、TV-out がある。Jz4725B に TV-out の機能を付けると却って高くなりそうだし。

届いたらレポートする予定。

    追記:2010/11/16 なかなか来ない。T555 は、生産中止・希望色 在庫切れだそうで.. 色変更するだけで 2 週間かかってしまった。今製造しているのは T556/T557 らしい。




ところでこれは何だろう? Mahdi が出している M18 Touch という製品らしいのだが、タッチパネルの上に(有線だが)コントローラが付いている。これが、Jz4755 だと面白いのだが ... Jz4755 とは限らない。

Jz4755 が載った E-Book -- EB70




aliexpress.com で 唯一 jz4755 でヒットするのは この 電子ブック EB70

値段は、$89.47 x 1 + $16.96(@EMS) = $106.43 。

液晶は普通の 7inch TFT LCD 800x480 だがタッチスクリーン 。メモリは 32MB , FLASH は不明(8GB まで)。バッテリー容量も不明(3300mAH まで)。 Wi-Fi: 802.11b/g が付いている。他の外部インターフェイスは microSD , イヤホン , スピーカー (マイクも? ) 。leather case が付属。

.. なんというか Android 端末を Jz4755 までダウングレードした感じ。

開発・テスト用ならこういうのも良いかも知れないのだが... 実用として使うならどうなのだろう?
CPU のクラスとしては、RK27xx よりは速いと思うが、RK28xx には負ける。そして、VPU や SIMD を使いこなしてはじめて本来の性能になるから、ファームウェアの出来が重要。
だが、肝心のファームウェアの出来が分からない。

Jz4760


ついでに Jz4760 について書いておこう



前に JZ4760 が出るらしいと書いたが、データシートから転載したらしいブロック図を発見。(url)

日付は、2010-08-20 で随分前の情報だ。ingenic のコードにも随分前から Jz4760 の対応が入っている。出るのは確実なのだろうが、いつになったら出るのだろう? 来年?

それはともかく、ありがたいことに英文の説明も付いている。たぶんこれもデーターシートからの抜粋。


  • XBurst Jz4760 is a mobile application processo targeting for multimedia rich and mobile devices like Smart phone, PMP, mobile digital TV, and GPS. This SOC introduces an innovative dual-core architecture to fulfill both high performance mobile computing and high quality video decoding requirements addressed by mobile multimedia devices.

  • The CPU (Central Processing Unit) core, equipped with 16K instruction cache and 16K data cache operating at 600MHz, and full feature MMU function performs OS related tasks. At the heart of the CPU core is XBurst processor engine. XBurst is an industry leading microprocessor core which delivers superior high performance and best-in-class low power consumption.

  • A hardware floating-point unit which compatible with IEEE754 is also included.

  • The VPU (Video Processing Unit) core is powered with another XBurst processor engine. The SIMD
    instruction set implemented by XBurst engine, in together with the on chip video accelerating engine and post processing unit, delivers doubled video performance comparing with the single core implementation.

  • The memory interface supports a variety of memory types that allow flexible design requirements, including glueless connection to SLC NAND flash memory or 4-bit/8-bit/12-bit/16-bit/24-bit ECC MLC/TLC NAND flash memory for cost sensitive applications.

  • On-chip modules such as audio CODEC, multi-channel SAR-ADC, AC97/I2S controller and camera interface offer designers a rich suite of peripherals for multimedia application.
  • TV encoder unit 10-bits DAC provide composite TV signal output in PAL or NTSC format.
  • The LCD controller support up to 1280x720 output, as well as external HDMI transmitter.
  • WLAN, Bluetooth and expansion options are supported through high-speed SPI and MMC/SD/SDIO host controllers.
    The TS(Transport stream) interface provides enough bandwidth to connect to an external mobile digital TV demodulator.

  • Other peripherals such as USB OTG and USB 1.1 host, UART and SPI as well as general system resources provide enough computing and connectivity capability for many applications.

    ざっとみて、Jz4750 から変わったのは、

    • CPU の周波数 360MHz(400MHz?) → 600MHz
    • FPU (浮動小数点演算ユニット)
    • DDR/DDR2 のサポート (SDRAM は未サポートになった?)
    • USB Device (HI-Speed) の OTG 対応。
    • 2D グラフィックスエンジンの追加。
    • MMC/SD/SDIO の数 2 → 3 等高速シリアル系の強化

    といったところか。機能的には Jz4750 のちょっとした強化版 のように見える。プロセスルールが 180nm → 130nm になるようだ。

    まぁ、最近の Android 向け 高性能 ARM チップには太刀打ちできない。だいたい RK2808 クラス。.. だが MIPS で カーネルソースや情報を公開しているということに意味がある。
    それに(おそらく)値段も安く、あまり高価でないPMPに採用されるはずで、開発して遊ぶには嬉しいポイント。

上にも書いたが これの PMP向け LQFP版 がでると嬉しい。.. だが、これを使いこなすには VPU の使い方がわからないと...

    追記:VPU の使い方は判った。Jz4755 で判らないのは、SIMD(60命令) → SIMD2(114命令) の差分ぐらい。

    2D グラフィックも判った。(Jz4760 データシート入手! ただし pm はない。)

    ― Up to 100M pix/s
    ― Up to 1080P
    ― Line/Rectangle
    ― ROP4/Alpha blending/Filter
    ― Rotation (90/180/270 degree)/Mirror
    ― 1 Rectangle Clip

    だそうだ。ようやく Rotation が出来るようになったわけだが ... キャッシュラインサイズ(32 byte) x 画面縦分の SRAM を持って 変換してから メモリに書き戻すとかしないと メモリ負荷がとんでもないことになりそう。いったいどうやっているのだろう?


追記: VPU の使い方が判ったと書いたが、Linux のソースには、説明がないものの定義が含まれている。VPU が出来ることは、IDCT, Motion Compensation(MC),Motion Estimation(ME),De-Block の 4つだが、MC/ME は定義がある。

よくよく見ると Programmers Manual にすらない OTP (One Time Programmable Module) の定義まである。
OTP には、(どのCPUかが分かる)プロダクトID や (ユニークなIDを作れる)ウェハのIDと位置が入っている。
.. これは嬉しいかも。

追記 20101122: New console in prototype stage
という記事が出てきた。

  • Ingenic 4755 (Dual Core Clocked at 400 MHz but can be overclocked to 550Mhz The second core is a VPU similar to a GPU)
  • 4.0 TFT LCD (Brand: King Display KD43G16-40NC-A3 Resolution: 480x272 Active area: 95.04mm x 53.86mm 262K color, 24bit parallel RGB interface)
  • 64MB SD Ram (Winbond W9825G6EH-6 (2 pieces) 4M words x 4 banks x 16 bits = 32 MB 166MHz/CL3 or 133MHz/CL2)
  • 2GB NAND (Samsung K9GAG08U0E 16 Gb = 2GB MLC, large block 8-bit interface)
  • MicroSD Memory Slot
  • D-Pad and Analog Nub on left
  • Standard A,B,Y,X on the right and L1 R1 Shoulder buttons on top
  • 4MP Video Camera/Camera
  • OS will be Dingux with hopefully a new menu system the fall back will be Gmenu2X



    プロトタイプ基板の画像も出ている。

    外観は、ありきたりな PSP タイプになってしまうようだ。
    (写真は他の人が予想したものだが、基板の形をみれば判る)

    基板だけ見ると Neo Slim 3000 とよく似ている。Hold スイッチがなかったり、カップリングコンデンサの容量が少なかったり デザイナーが同じじゃないかと思えるほど。それに加えて P5-5 のようなマイクロコントーローラも付いている。

    値段は、Estimated price $80 to $85 USD 。ファームウェアの開発にお金をかけていれば 妥当な気がするが... そうでなければ、ちょっと高めのイメージ。

    売れるかどうかは、オリジナルのファームウェア次第か。それが Dingux なら結構期待できるかも知れない。ただ Jz4755 用にカーネルを移植するのは 骨が折れそうなんだが、大丈夫なんだろうか?

    -- 勘違いしていたが、dingoo-digital から出ている情報らしい。本物の次機種?
    なら ファームウェア は期待できそうだ。だが、550Mhz までオーバクロックするのは本当なのだろうか? Jz4740 と同じ 180um なのに?

    -- dingoo-digital も dingoo-tech も関係ないと書いてきた。... ならファームウェアの問題は厳しそう。

    11/24 ウォッチしているんだが、Jz4760 モデルの話も出てきた。今から 9ヶ月後 .. そうかその頃か。



    まさか ... Get-Arcade Pocket Console (RMB320) のことだったりするのだろうか?

    4.3 inch で カメラ付いているし、2GB しかないし。写真さがすと microSD だし TV-OUT あるし。
    A320のチームが作れば Jz4755を選びそうなものだが ... 同じ形状の ものは 無数にある。

    やっぱり違うかも。
posted by すz at 21:04| Comment(0) | TrackBack(0) | Jz47xx

2010年10月01日

USBBOOT で LCD制御

A-41 の LCD は、コントローラで制御する Smart LCD 接続になっていることが判った。おそらく 兄弟機である A-33 も同じだろう。

  • Smart LCD 接続では、フレームバッファを用意して、定期的に 出力するような制御は不要になり、PORT を叩くだけで制御できる。

  • そのかわり、どのようなコントローラが載っていてどのようにコマンドを発行するのかという情報が必要になる。

  • Smart LCD なら、Linux でデバッグする前に、単純なプログラムで試してみることが出来るし、そうするほうが開発効率が良い。

... というわけで USBBOOT で動かせるプログラムとして LCDを制御するようなものを作ってみようと思う。

ピンのアサインについて

    LCD が どのように GPIO に割り付けられるのか? .. これを知らないといけないわけだが、SLCD コントローラを使う前提になるから、だいたいは決まってしまうのだ。

    LCD_DAT0-LCD_DAT17 (LCD の DB0-DB15(+ DB16,DB17) に接続)
    LCD_VSYNC( = SLCD_CS) LCD の WR
    LCD_HSYNC( = SLCD_RS) LCD の RS

    LCD の CS/RD を使う場合は別途 GPIOを(PORTD から)割り当てる。
     - A-41 では RD は 固定 (read しない/できない)

    Linux のコードだと PIN_CS_N / PIN_RESET_N が GPIO として定義されることになっている。RESET も GPIO かも知れない。

    追記:
    A-41 は、
     LCD RESET = 102 PD23 LCD_SPL(LCD)
     LCD CS = 103 PD22 LCD_CLS(LCD)
    だということが分かった。


コントローラについて

    そもそもこれがなにか分からない。だから試行錯誤しなければならないのだ。

  • A-41 では、ILI9325 が有力だが、違うかも知れない。

    FPC-TLN240T36A1 というのが載っているのだが、
    "FPC-TLN240T36A5 9325"でググるとなにやら沢山ヒットする。

  • A-33 は 400x240 なので、320x240 用の LCD コントローラは使っていない。ILI9326 か?

    ちなみに、ILI9325/ILI3926 では アプリケーションノートの PDF もあり、初期化例が載っている。

解析方法について

  • CSとRESET のピンアサインだけは、探す必要がある。CS(RESET) を プルダウンしてみて、GPIO を読めばたぶん分かる。
  • まずは、解析などせず ILI9325 だと思ってプログラムを作成し動かしてみる。全然だめなら解析する。

  • 解析は、ロジアナを使うつもりだが、16ch なので、16bit + RS/WR を一度には取れない。まずは、RS/WR + 下位8bit 分。
    これで、インデックス レジスタの設定を見て どういうレジスタを使っているかを知る。

  • それであたりが付けられなかったら RS/WR + 上位 8bit も取る。同じシーケンスのはず(RD がないから状態によってシーケンスが変わらない)だから、全部が分かるはず。

  • でも、まずは 解析の練習を フォトフレーム KDPDK24 でやるつもり。
     - オリジナルのファームウェアを消す段階になったら、8bit タイプの LCD に交換するのも良いかも知れない。なぜなら 8bit 分GPIO が空く。多分 GPIO の空きは 0 だから貴重。

  • 問題は、テストピン。外れたりすると面倒だから 配線をハンダ付けしてしまうかも。配線材は、ピンヘッダ用接続ケーブル[CB-PH10P-250] を切って使うつもり。

     - PDPDK24 の 20pin の空きパターン(1.0mm ピッチ)でハンダ付けしているのだが、線が太すぎてなかなか難しい。
     - ちょっと反則だが、
      
     これを切ってテストピン代わりに付けるか。
    - 強度が足りなかった。プローブ付けたらもげてしまった。
    - やはり ハンダ付けか。

追記:

    PDPDK24の分析練習は終了。ST7785 か そのあたりのコントローラのようだ。2Ah(CASET), 2Bh(RASET), 2Ch(RAMWR) の繰り返しで画面を更新している。

    picfun: 2.4/2.8インチ QVGA液晶表示器の制御 に、ILI9325 のライブラリがある。LCD が使えるかどうかのテストならこれを参考にしたほうが分かりやすい。

バスについて



  • ILI9325 で 16bit アクセスをする場合、DB17-10 が上位 8bit / DB8-1 が下位 8 bit 。ちなみに、8bit アクセスする場合 DB17-10 に接続し、上位→下位の順で 2 回 Write する。(8bit 用のコードを参考にするのに必要な情報)

    16bit アクセスすると 決め打ちしているが、IPU が使える条件は、32bit (R8G8B8) か 16bit(R5G6B5) しかない。IPU を使わないと 動画性能が落ちるのでかならず使っているはず。


追記:実際のコードを組んでみる。

RESET と CS は判ったので、コードを組みはじめることはできそうだ。(確認したのは、A-33 だが、A-41 も同じだと思う。)

で、A-41 は ILI9325 だと思うので、これ用のコードを検討する。

まずは、ILI9325AN -- アプリケーションノートにあるコードを見てみると ... いくつかのパネルに対してのコードが別々になっていた。

コードを比較してみると ..

  • 初期化の電圧設定 と ガンマ曲線の設定のみが違う。
     - 違うパネルのデータを使っても 表示だけはできそう。
  • ついでに ILI9326AN を見てみると、ILI9325 と手順はほぼ同じものの、レジスタのアドレスと値が違う。各パネルの違いは、ILI9325 と同じような感じ。

とりあえず、アプリケーションノートにあるコードを元にして picfun のコードを参考に プログラムを作成しようと思う。


ちょっといくつか ILI93xx の コマンドリファレンスを 切りだして 画像にしてみた。描画エリアと 描画方向を指定して データを連続で送る ... ということは出来ると思うのだが .. コマンド体系は同じように見えるが、それぞれコマンド自体は違うようだ。


    picfun のコード(ILI9325)だと、
    ST7785 での、2Ah(CASET), 2Bh(RASET), 2Ch(RAMWR)がそれぞれ
  • 0x20 : Horizontal GRAM Address Set
  • 0x21 : Vertical GRAM Address Set
  • 0x22 : Write DATA to GRAM
    に相当している。
    ILI9326/ILI9328 も同じだが、ILI9327 は、2A/2B/2C で ST7785 と同じ。

これだけで描画するというのもひとつの手だ。ただのテストなのだから 凝ったことをする必要はない。

GPIO のアクセス方法

    bit 単位の set/clear 関数はマクロにあるのだが、まとめてアクセスする関数は定義されていない。どのようにアクセスするものなのかまずはチェック

    • GPIO 関係の レジスタは、3 つ 1組みになっている。Read-only の xxx というレジスタに対して、Write-only の xxxS/xxxC というレジスタがある。機能は、該当ビットを 1 にする (xxxS) / 0 にする (xxxC)。-- 以下 xxxS/xxxC については省略して説明。
       - 複数bit の 値を 1 オペレーションで設定することはできない。
    • xxx は PAyy,PByy,PCyy .. とネーミングされているが、マクロは PXyy となっていて統一的に扱う。以下の説明でも PXyy を使う。
    • PXIN -- 入力に設定されたとき ピンの値が読める。
    • PXDAT -- 出力に設定されたときの GPIO の値。
    • PXFUN / PXSEL -- この 2 つで GPIO として使う設定になる。0/0 が GPIO 。
    • PXDIR -- GPIO の方向。1 で 出力。
    • PXPE -- pull-up または pull-down (PIN によって決まっている) の設定。0 で pull-up/pull-down。

      まとめ
    • 出力設定 PXFUN = 0 , PXSEL = 0 , PXDIR = 1
    • 入力設定 PXFUN = 0 , PXSEL = 0 , PXDIR = 0
    • 出力 H: PXDAT = 1 / L PXDAT = 0


delay について

    コードには、delayms など ms 単位での待ちをいれている。これをちゃんと実装しないと、まずそうだ。
    また、GPIO のアクセスで WR のパルス幅をコントロールしないといけない。適当に作ると 早すぎて コントローラの条件を満たさないかも知れない。

      USBBOOT では 228 MHz が デフォルトになっている。1 clock 4ns ぐらい。

    Linux のコードを参考にして、__delay(loops) と mdelay(ms) を作ろうと思う。具体的には、

      #define CPUCLOCK 228000000

      static inline void __delay(unsigned int loops)
      {
      __asm__ __volatile__ (
      " .set noreorder \n"
      " .align 3 \n"
      "1: bnez %0, 1b \n"
      " subu %0, 1 \n"
      " .set reorder \n"
      : "=r" (loops)
      : "0" (loops));
      }

      static inline void mdelay(unsigned int ms)
      {
      int i;
      for (i=0; i<ms; i++) {
      __delay(CPUCLOCK / 2000);
      }
      }

    これ。__delay の 1 loop は 2clock のようだ。




A-41 の LCD に表示できた。

  • WK11: usbboot-wk11.tar.gz

  • 16bit の ILI9325 用のコードで画面クリアが出来た。
     - 青、緑、赤で 全面の塗りつぶしも OK で、予想通り R5G6B5。

  • ただし、最初は安定しなかった。時々画面が白のままになる。
     - delay を増やすことで、正しくクリアできるようにはなった。

      タイミングのチェック:
    • CS/RS/データの確定後 10ns 待って WR を ↓。
    • 50ns 以上(500ns 以下)待って WR を ↑
    • 40ns 以上待って 次のステップ。

     - 追記: ILI_93XX_Reset() が適当だったので安定しないことがわかった。
      普通に clear/set するようにしたら 安定した。

  • フォントの描画コードも入れている。
     - 表示はできているが、現状は色がおかしい。
      → バグがわかった。
     - デバッグに利用できるのももうすぐ。
      → スクロール機能が必須。
  • ILI9326 用のコードも作ったので、A-33 でもやってみたいが、予備が届くまでおあづけかな。
     - バッテリー充電機能が不明なので、いちいちバッテリーを外している。これが面倒。
     - だが使えることを確認して安心したい。

A-33 も動いた。

  • WK12: usbboot-wk12.tar.gz

    結局、制御できるかどうか安心したくて、やってみることにした。

  • ILI9326 16bit インターフェイス用のコードが動くことが確認できた。初期化のコードは、アプリケーションノートから取ってきたものだが、他は、ILI9325 用のコードをベースに レジスタ番号を ILI9326 に合わせただけ。あっさり動作した。

  • 画面サイズは、横 240 x 縦 432 だった。(A-41 は 横 240 x 縦 320)

    これで一安心。

    Linux 移植でのデバッグでも 情報を画面に 残せるようなる。これをベースにして jz_ubcomm ドライバ に組み込む予定。(正規の SLCD ドライバは別途考える)

      A-41 から I2Cを引き出して LED を点灯できるようになったのだが、ほとんど使わないうちに いらなくなりそうだ。

      Neo Slim 3000 の方は、Smart LCD 接続でなく RGB インターフェイス。こうなると、A-41/A-33 で進めたほうが 良さそうだ。

      ところで、予備を everbuying で 2 つ 買っているのだが、売り切れで 1 つしか入手できないという連絡があった。結局差額を支払って A-32 にチェンジ。A-33 とだいたい同じ兄弟機のはずだし、中を見たいし、A-33 ほど安っぽくはないし .. まぁいいか。

    これで LCD制御はひとまず完了。

    • Linux で主に使うのは、フレームバッファの転送だけなので 凝った機能を使わない。SleepMode に入る/出る という機能もあるが、アプリケーションノートそのままだし。

    • いずれ P5-5 にも 手を付けると思うが、先のはなし。

    おまけ: ILI9325 メモ

    • R03h : Entry Mode
       (9326 では、R03h = R003h)

      D15/D14 : TRI/DFM = 00 → 65K mode
      D12 : BGR = 1 → swap R and R (??)
      D5/D4 : I/D = 11 → incliment/decliment:
                      V inc , H inc
      D3 : AM = 0 → update direction = Horizontal

      例:
      ILI93XX_CtrlWrite(0x03, 0x1030);


      TRI/DFM の設定で、16bit モードでも 256K Color の書き込みができる。ただし、2 回の書き込みが必要。(8bit モードでは、3回)

      BGR=1 と下記の REV=1 で、RGB データを逆順にできる。何故か逆順が 普通に R5G6B5 としてアクセスできる設定。

      重要なのが、I/D と AM 。データを書き込む方向を指定するもので、これを使えば画面を回転させられる。

    • R61h : Gate Scan Control
       (9326 では、R61h = R401h,R6Ah = R404h)

      D2 : NDL = 0 → Non-Display Area = black ?
      D1 : VLE = 0 → virtial scrolling = disabled
      D0 : REV = 1 → change endian

      例:
      ILI93XX_CtrlWrite(0x61, 0x0003);
      ILI93XX_CtrlWrite(0x6A, vscroll_base);


      NDL は、表示外エリアが白か黒かを指定するもの。
      REV は、それぞれ R,G,B の MSB の指定。

      VLE は、縦スクロールの許可。これを使えば長辺方向にスクロールできる。Linux の本来のドライバは、フレームバッファから転送するので必要ないが、デバッグでコンソールもどきにするとき欲しい機能。

      とりあえず Pixel 描画以外に、これだけ知っているだけで十分使える。

      あとガンマ曲線の設定を理解できれば、好みの色調に出来て嬉しいかも。

      それ以外で気になるのは...

    • R2BHh : Frame Rate
       (9326 では、R20Bh だが値の意味が違う)

      デフォルト 96 Hz だが、40 Hz まで落とせる。(9326 では、デフォルト 80 Hz / 最小 30 Hz)

      ひょっとして、フレームレートを下げると液晶本体の消費電力もかなり減ったりしないのだろうか? 一度調査してみたい。

    ちょっと修正。

    • WK13: usbboot-wk13.tar.gz

      上記の RESET の操作を修正。
      あと、exec コマンドを追加。0x80600000 にロードして go する簡易コマンド。

      まだ動いていないが、MinGW で動くように気がついたらコードを修正している。
posted by すz at 23:53| Comment(0) | TrackBack(0) | Jz47xx(USBBOOT)

2010年09月30日

A-41 写真集

解析用に写真を取り直した。コメントなどは、Aneca A-41の記事に書く。














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

2010年09月27日

P5-5 分解

P5-5 (PMP3100後継機)の記事の続き。

P5-5 を分解してみることにした。どうせ PMP-3100 と同じだろうと思っていたのだが随分違っていた。

まずは、おさらい。




    これが PMP-3100 の中身。CPU が Jz4725(無印)なのと、液晶側に 14pin の謎の IC(おそらくボタン用) があるのが特徴。-- 実をいうと こういうのを解析するのにロジアナが必須だと思いロジアナを買ったのだ。で、練習に分析してみようと思ったわけ。





これが、P5-5 の中身。基板の色が変わって SDRAM,FLASH の配置が変わっている。

そして、14pin の IC がなくなり代わりに 左上に 8pin の IC が付いた。そしてボタンへの配線が すごくシンプルになっている。



これが、そのあたりの写真。例によって 8pin IC の刻印が消されている。

    pin #8 は GND 。pin #1 は コンデンサがつながっているので VCC だと思う。... PIC のような気がする。
    それはともかく、6 本の I/O ピンでいったいをしているのだろう? ボタンという可能性はまだある。ADC があれば、多重化できる。(PIC なら ADCは pin #3,#5,#6,#7) -- ボタンの配線がシンプルになっているので 合っているかも。

T1 のマークが TxD 。その下の 平行な 2 本線が I2C(SCK,SDA の順)
あと、他の写真。



FM モジュールと イヤホンジャック周り。FMモジュールは、SP3767AHN の刻印。カップリングコンデンサが、47uF/10V になっている。

I2C(左から SCK,SDA の順)が平行なまま伸びてきていて、103(10KΩ)でプルアップされ FM モジュールに接続されている。



コイルがあるあたり。コイルとその近くの SOT23-5 は、core 電圧用。空きパターンは、バックライト電源の昇圧用?

T2 がある。これは何?



SOT23 がやたらあるところ。8pin ICはバッテリー制御用?

SOT23 の刻印は、M21 6620 MO 1AM(x2), あと SOT23-5 の LB26

下の A106 は(たぶん)タンタルコンデンサで 10uF 。その左上の黒いのはコイル? そしてコイルの先は LB26 の pin #1 。

8pin IC の刻印ははっきり見えるが、読めない。XX690M 。XX は 11 のような形をしているが 11 とは思えない。



最後に CPU 周り。一応。

部分写真は、はっきり刻印が撮れた。ちょっと A-41 とか A-33 もがんばってみよう。

ところで、スピーカーとバッテリーのケーブルは取ってしまった。
どこにつなぐのか忘れないようにメモ。

  • 左端中央 四角で囲んであるところ + がスピーカー(青) - がスピーカー(赤)。
  • 右端中央にも おなじような四角がある。おなじようにスピーカーを接続。
  • 左端の 四角の左。+とー が見える。これが バッテリー

posted by すz at 06:13| Comment(0) | TrackBack(0) | Jz47xx(機種解析)

2010年09月21日

SDRAM換装に挑戦

SDRAMの換装方法(案)という記事を書いたが、いよいよそれを実践してみようと思う。

予定では、

  • ターゲットは、A-41 。

  • 32MBを まずやって、いまくいけばもうひとつを 64MB 化する。

      不安材料は、工作技術以外には、電源。-- 16MB と比べれば 32MB,64MB は大食い。しかも A-41 はあまり電源は強くなさそう。

  • ケースから出さずに、バッテリーを外して作業するつもり

だったのだが...

まずは、SDRAM を外す作業。

興味から買っていて死蔵しているサンハヤトの表面実装部品取り外しキット SMD-21 を使う。

キットには、低音ハンダの他に特殊フラックスとハンダ吸い取り線が付いている。特殊フラックスは、注射器のようなタイプで、一回使った後の保存に不安があったので、今回は普通の無洗浄フラックスにしてみた。

両面テーブでLCDに貼られているバッテリーを外して作業するつもりだったのだが、両面テーブが強力でLCDを壊しかねないので、ケースから取り出して作業することにした。バッテリーは、電線を基板から外すだけにした。



外した後、低音ハンダを吸い取り、1回普通のハンダを盛ってまた吸い取っている。(低音ハンダを残さないようにするため。)

その後、アルコールを綿棒に付けて掃除した後の状態。

そういえば、A11 。16MB では NC の A11 の線があるかチェック .. 右下 (写真では 左下) から GND A4,A5,A6,A7,A8,A9,A11 .. 配線されている。大丈夫そうだ。



次に、aliexpress で購入した SDRAM の足が曲がっていないかチェック。-- OK そうだ。



これが、SDRAM を 付けた後。

付けようとしたときに、気がついたのだが、64MB だった。
まぁどうせ後で付けるんだからと思い、そのまま進めることにした。

ハンダ付けは、半田ごてで押さえるだけにした。

で、目視でチェックして、電源を入れてみた。

全然動かない。

原因が、ハンダ付け不良なのか、電源なのかもわからない。

切り分けるために USBBOOT を試すことにした。USBBOOT は、どんな回路でも動作するように、低クロックで立ち上がるはず。それで立ち上がるなら、電源が原因のはず。

.. ということで、ケースに一旦戻し やってみた。

... 中途半端に動く。USB は認識されるのだが、不明なデバイスになる。

たぶんハンダ付け不良。

それはともかく、バッテリーを外した状態で USB に挿して立ち上がるものなのかどうか確認していなかった。

というわけで、もうひとつもバラすことにした。

で、まず確認。-- 普通に立ち上がる。

ついでにこちらも換装してしまうことにした。



今回は、ランドに残すハンダを多めにしてみた。

    ところで、表面実装部品取り外しキットでは、16cm の低温ハンダ x 5 で、約1,500ピン分取り外しができることになっている。

    今回 2 つで 1 本の 1/2 ほど消費した。54pin x 2 だから 110 ピン (1/10 で 110 ピン) -- 少々使いすぎかもしれない。

    使いすぎると 低温ハンダの除去が面倒なのだ。少し慣れたから次回はもっと少なくできるだろう。

    2 つやってみての所感。

    とりはずしは、15W のハンダごてでやったが、特に問題なかった。問題はその後。ハンダ除去がなかなか 面倒。

    ハンダ除去後、とても汚くなる。残っているのかどうかもはっきりしないので、清掃は必須。綿棒とアルコール(手持ちの 無水エタノール)で十分だった。

    注意したことは、低温ハンダが 他のパーツにつかないようにすること。少々混み合っているので、角のところを 丁寧に。(ハンダ除去も)



一応チェック。今回は間違いなく 32MB 。

そしてハンダ付け -- ハンダ付け不良がないように念入りにすることにした。

で、電源を入れる。やっぱり動かない。何回かやってみたところ 1回だけ立ち上がった。

ハンダ付けが十分でなく、接触不良のようなことになっているのか? それともやはり電源なのか?

ケースに入れ USBBOOT をしてみたところ、ちゃんと 認識された。
何度かやってみたが、ここまでは問題ない。

... ケースに入れてしまったので まずは、どこまで動くのか確認しようと思う。

    stage1 は動く。その後の stage2 のロードは終わるが、制御を渡したあと帰ってこない。-- アドレス線 のどれかが 不良?

ちゃんと動くのであれば、電源を強化しなくてはならない。どう強化すべきなのかの参考にするため、記念写真。


(A-41 1号機 64MB)


(A-41 2号機 32MB)

電源IC について

    写真を良くみると .. MicroSD の左の SOT23-5 は A2IK 、コイルの下にある SOT23-5 は A18T と印字されている。

      コイルは、10uH 。周りにダイオードがない。
      同期整流タイプの電圧下降型 DC/DC には、TOREX
      XC9236A18CMR とか FAN5307S18 とか SC189 とかがある。
      いずれもピン配置は同じで

         (1) Vin Lx (5)
      (2) GND
      (3) EN Vout (4)

      たぶん、これもそうだろう。10uH を使っているということは、あまり高いスイッチング周波数ではなく 1MHz 台ではないか?

    A2IK は、G9091 ? (G9091 は、LOD で 最大 300mA もれ電流 65uA )。互換性があるのは XC6204 , XC6219 らしい。( 最大 300mA のタイプは 型番に E 〜 H が付く)

    出力は 5番ピンだから、そこの先 .. 右上の 大きめのコンデンサが出力につくコンデンサ。入力は 1 ピンで たぶん 左の 下から 2 番目の小さめなコンデンサが 入力に付くコンデンサ。

    A2IK が CPU, SDRAM をはじめとする 3.3V を供給しているのだろう。

    基板右下に SOT23 と SOT23-5 が見える。SOT23 は D2E と読めるが、SOT23-5 は写真ではわからないが T25a と印字されている。

    そして SOT23-5 の右のチップ、これだけ黒い -- コンデンサではなく コイルかも知れない。

    D2E は 1個入りダイオード(RB491D とか)。 SOT23-5 は LCD バックライト用の 昇圧型 DC/DC コンバータ IC かも知れない。

    近くに 4R7 がある。電流測定用? 他には 4.7K(472),10K(103) だけ。

    たとえば、FAN5333A なら、

       (1) SW Vin (5)
    (2) GND
    (3) FB /SHDN (4)

    というピン配置(他のICもこの配置が多い)。 (2) に GND が来ているように見えるし、(1) からダイオードの方に太めの線が伸びている。-- たぶん合っている。

    FB の電圧は、110mVで、4R7 だと 23mA 。

      だが ... そうなると リポ電池 充電用の IC はどこにある?

      SOT23-5 は、全部で 3 個あるが、どれも 充電用ではなさそうだ。バックライトの PWM はわざわざ RxD 機能兼用の PWM3 を使って 兼用機能のない PWM5 はなにか別の目的に使っている。... いやな予感がしてきた。

    • A-33 について:
      A33 にも 3 つの SOT23-5 の IC が付いている。ひとつはインダクタ(100) の横にあるやつで、D19m と印字されている。印字は違うが、1.8V 用以外にはありえない。あとのふたつは A2JB だった。ひとつは LED 専用のレギュレータ?
      -- それはともかく、双子のようなマシンだし やはり 充電用 IC は見つからない。
      相当に不安を感じる。どんな回路で充電しているのか解析しないと ..

    ついでなので、スピーカーアンプについて。SDRAM の左にある 8ピンのICがアンプ(BTL)。写真では全く印字が見えないが LN4890 らしい。これは、Neo Slim 3000 に載っている XPT4890 互換らしい。... といっても互換品は沢山あり、LM4890, TPA2005D1 など。

    さらについで。目立つ FMラジオの空きパターン。これのピン配置

    (5) GND 3.3V (6)
    (4) R-LINE W/R (7)
    (3) L-LINE MODE(L) (8)
    (2) NC SCL (9)
    (1) ANT SDA (10)

  • SCL/SDA が、2.2K(222) でプルアップされているようだ。少々低抵抗値 10K にすべきでは? (ちなみに、実際に FMラジオが付いている Neo Slim 3000 では 4.7K(472) でプルアップ。付いていない A-33 は プルアップのパターンだけ。)

    ちなみに、SCL/SDA は 4mA のクラスの I/O ピンで Typ. なら L 7.4mA / H 10.2mA 流せることになっている。... ここに LED を つなげて デバックするのも良いかも知れない。

  • I2C なら 8 番の MODE が L レベルになっているはず。ライン入力は、付けるデバイスから数字をとると 115 mVr(フルレンジとは限らない)。
  • 3.3V は、FET スイッチ 経由かも知れない。どれだけ電流を取れるか不明。
  • FM モジュールは、なぜか bottom view 基準で番号が付いていて、上下が逆になる。


32MB 化したマシン(2 号機、識別シール 黄色) が動いた !



写真を見ていたら、JZ4725B の足にハンダが 飛んでいた。
これを 細いものでゴリゴリして外したら ... 立ち上がった。

あとは、64MB 機 (1 号機 識別シール 緑) 。

写真を見ると、左側はハンダ付けされているように見えない。ハンダの盛りが少ないのに 押さえるだけなのは無理があった。( すこしランドに ハンダを盛っておけば良かった)

ハンダ付けをちゃんとすれば動くかも知れない。

    ちなみに .. 今回の電子工作は、かなりテキトーにやっている。それは、1回 2回の失敗ならまた買えばよいと思っているから。

    今回のような ショートが起きたら、IC が破壊されるかも知れない。失敗したくないなら、やはりちゃんとチェックすべき。

    今回はテキトーだといっても 一応 気を付けたことはある。ちょっと書いておくと

    • バッテリーは必ず外す。
      電源スイッチがあるといっても RTC は通電されている。今回のようにショートしたところが RTC 周りだと結構やばい。
    • 外す際、力をかけない
      ランドが剥がれたらもう失敗確定。決して力をかけて外さない。
    • SDRAM を付ける前に ランド間のブリッジをチェックする。
      ブリッジがあると SDRAM を付けたあとではどうにもならない。いまはデジカメがあるので、(ちゃんと撮れるなら)写真のほうがわかりやすい。
    • 清掃する。
      写真をとっても良くわからないかも知れないので、綺麗にしておく。
      よく見ると、ハンダが玉になって 基板に付いていたりする。こういうのを取っておくためにも、綿棒を使って綺麗にする。


64MB 化したマシン(1 号機、識別シール 緑) が動いた !


SDRAM のハンダをつけ直したら立ち上がった。ケースにいれたところ、また動かなくなったので、再度やりなおしたら動いた。ケースに入れても OK 。



実をいうと、バッテリーを取り付けるあたりが、ホットボンドで汚いので、地道に取り除いたりしていた。ついでに、FM モジュールのパターンにハンダを盛ったりも。



さらに水晶周りも、ゴム系の接着剤で汚かったので剥がしたりもしてた。写真では、32.768 が見えている。右の水晶は、12.000。ちょっとやりすぎて足が外れたりしたので、つけ直している。

12.000 の 刻印 は下向きにしてしまったので見えない。

このマシンを Linux の移植ベースにしようと思う。

.. とか書きつつも既にこんな状態




デバッグ用に 1608サイズLED(,)を付けた ボードを作り それに接続するつもり。

    よく考えたら、2.2K のプルアップが付いている。H レベルで点灯するようにすると プルアップで点灯してしまうかも知れない。
    それに、I2C は、Hi-Z と Lレベルで通信する。H レベルにするのは、まずいケースがあるかも知れない。。

    L で点灯するようにした。電流制限抵抗は、 300Ωにした。
    ( 3.3 - 1.7 ) / 300 : 5.3mA の計算なのだが、これでも明るすぎる。1KΩでも良いのかも知れない。


シリアル TxD は使わない。引き出すのは出来そうだが耐久性に難がある。あと、シリアルに頼らないデバッグに挑戦したい。

改造メモ

電子工作で、どんな改造をしてみたいかのメモ:

  • カップリング コンデンサ の付け替え (A-33)
    47uF を 100uF にする。
    低音が出るようになるか 見てみたい。
    P5-5 も 47uF でダメだが 抵抗の変更も合わせてする必要あり。

  • SDRAM 換装 (A-33)
    調子に載って A-33 も改造する。2 台の A-33 のうち 1 台は 32MB に。
    バッテリーのもちは、確実に悪くなるが Linux を動かしたい以上 やむを得ない。
    残り 1 個の 64MB は温存。Linux が動いたものの中で選択。

  • I2C のプルアップ抵抗の取り外し(A-41)
    忘れていた。A-41 の 2.2KΩ を 外して 10KΩにするか 、外したままにする。( A-33 は付いていない -- どうするか考えて統一しよう)

  • I2C 引き出し (P5-5)
    まずは、不明なFM ラジオモジュールの解析ができるか練習。
    うまくいけば、謎IC の解析にも挑戦。

  • SDRAM 換装 (8bit-64MBx2)
    これはあきらめてはいない。が、Linux が動き 実際に 64MB で不足するところまで来たら考える。
    候補は、2 段にするスペースがある P5-5 か A-33/A-41(新たに買うかも) 。(Neo Slim 3000は液晶が上に載るので無理)

  • E705A の USBBOOT アダプタ。
    買ってはみたが死蔵状態。USBBOOT は、USB デバイスの線を外に引き出さないと不可能。分解しなくとも 端子は出ている。この端子をどうやって引き出すか悩んでいたが、microSD/SDカード 変換を分解すると、使えそうな 端子が出てきた。
     - SDカードソケットの端子使ったほうが良いかも。ソケットは、100均 の SDカードリーダー分解しても取り出せる。

    これも PMPでLinuxが動いた後の話。


追記: ところで、増やした RAM は、オリジナルのファームウェアで役に立つのだろうか?

基本的には、役に立たない。なぜなら 汎用マシンではないからだ。搭載されているメモリで動作するように作られているわけだし、それ以上は使おうとしても使えない。

ただし、DISK のキャッシュ (PMPだから MicroSD/SDカードのキャッシュ)があり先読みしているとすれば、役に立つかもしれない。実際 MicroSD/SDカード から動画を再生すると、時々息継ぎみたいな現象が起きる。これが直ると嬉しいといえば嬉しい。

それはともかく、次のことをしなければ、使えるものも使えないだろう。

  • SDRAM の設定。Jz47xx では EMC に対して行う。設定しなければ、メモリは使えない。通常この処理は ブートローダの仕事。なぜならば、カーネルを ロードするために 必要だからだ。そして、設定を変えることはできない。
  • メモリ量の カーネルへの通知。カーネルによっては自分で調べるかも知れないのだが、通常そのような無駄なことはしない。もちろんブートローダの仕事。


さて、こういうことを調べるにはどうしたらよいのだろう?

まずは、ブートローダを逆アセンブルしなければならない。バイナリの逆アセンブルは厳しいので、一旦アセンブラを通す。

  • 適当な Cファイルを作って、-S オプションで アセンブラソースを作る。
  • バイナリを 変換する プログラム( or スクリプト)をつくり、
       .byte  0xXX,0xXX,0xXX ... 
    という形式にする。
  • 最初に作ったアセンブラソースの 中身を抜いて 変換したデータと入れ替える。
  • コンパイルして、mipsel-linux-objdump -d で逆アセンブルする。

こういう手順で作れるのだが ... それをどうやってみるのか?


  • EMC の BASE アドレス は、0xb3010000 である。
  • mips では 32bit を一度にロードすることはできず、

    lui 0x3b01

    という風にする。
  • 逆アセンブルしたものに対して 0x3b01 というパターンを探す。


探してみると A-41 では 9 ヶ所出てきた。... そういえば Neo Slim 3000 は 32MB だ。どうなっているのだろう? .. と思い見てみると ... 8 ヶ所。そのうち 前の 4ヶ所は アドレスが一致。

ソースのベースが同じなのだろう。設定自体は たぶん簡単で バッチも作れそう。... だが、カーネルへの通知は難しい。2 つのブートローダを完全に理解できれば、あるいは可能かも知れない。

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

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)