ページ

2015年8月31日月曜日

Buffalo WBR-G54 のシステムメモリ 32MB 化

フラッシュメモリのバックアップの終わった バッファロー WBR-G54 のシステムメモリを 16MB から 32MB へ拡張しました。

メモリチップの交換

作業は以前行った WLA-G54 と全く一緒の作業を行いました。現在搭載されている二枚の 8MB SDRAM (VG36641641DT-7L) を取り外して、新しく 16MB SDRAM (MT 48LC8M16A2-75) をハンダ付けしました。
Buffalo WLA-G54 のメモリ増設
http://near-unix.blogspot.jp/2015/07/buffalo-wla-g54.html
元々搭載されていた 8MB SDRAM の VG36641641DT-7L です。
コテライザーのホットブローによってチップを取り外しました。
中央部の R320 もホットブローの熱で外れてしまいました(笑)。
ランド部分をハンダの吸取り線で綺麗にハンダを除去しておきました。
外れてしまった R320 はハンダ付けしておきました。
新しく16MB SDRAM (MT 48LC8M16A2-75) を取り付けました。


使用した SDRAM の MT 48LC8M16A2-75 は、WLA-G54 に取り付けたものを取り外して、本機へ再度ハンダ付けしました。何度もハンダ付けを繰り返したため、メモリチップのリード線が若干曲がりが大きくなっていて、ハンダ付けが難しくなっていました。ちょっと多めのハンダの盛り付けで何とか動作させることができました。

NVRAM の設定

メモリチップの交換によって 32MB 化されましたが、まだファームウェア上では 16MB の認識となっています。そこで NVRAM の設定を変更して 32MB の全域を認識させるようにしました。設定した値は WLA-G54 と全く同じ値を設定しました。
nvram set sdram_init=0x0c29
nvram commit
reboot

再起動後、DD-WRT のステータス画面を確認すると 32MB のメモリ全域を認識していました。

DD-WRT のステータス画面で 32MB 化されたことを確認しました。

これで WLA-G54 で検証することが出来なかった USB ポートの設置が出来るようになりました。OpenWrt Attitude Adjustment 12.09 をインストールした後、USB ソケットの取り付けなどを行なってみたいと思っています。

Buffalo WBR-G54 の CFE のバックアップを検証

先日 JTAG にて CFE のバックアップを行なっていたバッファロー WBR-G54 ですが、JTAG の動作の不安定さから一抹の不安もありました。そこで DD-WRT の機能として備わっている CFE のバックアップ機能を使って CFE をバックアップして JTAG でバックアップした CFE と比較してみることとしました。

WBR-G54 へ DD-WRT をインストール

操作をするパソコンと WBR-G54 をイーサネット・スイッチを経由して接続します。

WBR-G54 からイーサネット・スイッチを経由してパソコンへ接続します。

操作するパソコンの IP アドレスを 192.168.11.2 へ設定します。(192.168.11.2 から 192.168.11.254 までのアドレスを選択)

操作パソコンの端末から次のコマンドで DD-WRT をインストールします。
$ tftp 192.168.11.1
tftp> binary
tftp> trace
Packet tracing on.
tftp> rexmt 1
tftp> timeout 60
tftp> put dd-wrt.v24-13491_VINT_std.bin
-- ここで WBR-G54 の電源を投入します--
sent WRQ <file=dd-wrt.v24-13491_VINT_std.bin, mode=octet>
sent WRQ
<file=dd-wrt.v24-13491_VINT_std.bin, mode=octet>

sent WRQ <file=dd-wrt.v24-13491_VINT_std.bin, mode=octet>
sent WRQ <file=dd-wrt.v24-13491_VINT_std.bin, mode=octet>
     ↓
     ↓
received ACK <block=7400>
sent DATA <block=7401, 0 bytes>

received ACK <block=7401>

Sent 3788800 bytes in 131.7 seconds

tftp> quit
$

以上でパソコン側の操作は終了です。フラッシュメモリへファームウェアを書き終えるまで 2 〜 3 分程度待ちます。そしてパソコンの IP アドレスを 192.168.1.2 または DHCP で自動設定に変更して、ブラウザにて 192.168.1.1 をアクセスすると DD-WRT の設定画面が表示されます。

WBR-G54 へインストールした DD-WRT の設定画面

DD-WRT による CFE のバックアップ

DD-WRT が正常に動作していることを確認した後、ブラウザで次の URL へアクセスをします。するとダウンロードの案内ダイアログボックスが表示されますので、cfe.bin をダウンロードします。
http://192.168.1.1/backup/cfe.bin

バックアップした CFE の比較

ダウンロードした CFE と JTAG でバックアップした CFE を比較します。比較は md5 のハッシュ値を比較しました。
$ md5sum cfe.bin WBR-G54.CFE.BIN
99efda3f23780918712232d3942ceb36  cfe.bin
99efda3f23780918712232d3942ceb36  WBR-G54.CFE.BIN

cfe.bin = DD-WRT でバックアップしたもの
WBR-G54.CFE.BIN = JTAG でバックアップしたもの

同じハッシュ値であったことから、同じデータのバックアップであったことが判りました。これで CFE は正しいデータであることが証明されました。また JTAG も正常に動作していたことが証明されました。

Buffalo WLI2-TX1-G54 の筐体洗浄

昨晩、分解とフラッシュメモリのバックアップを試みた バッファロー WLI2-TX1-G54 の筐体を洗浄しました。

筐体の表面はすでに雑巾がけをして綺麗にしていましたが、やはり筐体の内側はかなりホコリの黒ずみが付着していました。いつものようにレンジ周り用の強力アルカリ洗剤で綺麗にしました。掃除はいつ行なっても気持ちのよいものです!

洗浄中の WLI2-TX1-G54 の筐体です。


PHILIPS 無線 LAN カード PH12127-B を入手

フィリップス・ブランドの無線 LAN カード PH12127-B をインターネット・オークションにて入手しました。

今回入手したフィリップス PH12127-B です。

ThinkPad 用のオプション部品の扱いのものです。ドライバ CD や超簡単な多言語の取扱説明書も一緒でした。

PH12127-B 本体の他、カード抑え金具やマニュアル類も一緒に入手しました。
かんたん過ぎる取説(笑)

ThinkPad R32 へ取り付け

今回入手した無線 LAN カード(PH12127-B)は、純正無線 LAN カードの判定が厳しい ThinkPad R32 へ取り付けたいと思って入手したものです。早速この無線LANカードを ThinkPad R32 の底面の蓋を開いたところにある Mini-PCI ソケットへ装着してみました。


PH12127-B を ThinkPad R32 へ装着してみました。
ThinkPad R32 へ PH12127-B を装着したところです。

どきどきしながら ThinkPad R32 の電源を投入してしばらくすると、いつもの嫌な画面が表示されました。この IBM 純正品の無線LANカードであっても、特定の無線LANカードしか受け付けないようです(涙)。警告コードに "01C9" が存在することから、Atheros のチップを使用した無線 LAN カードのようです。

ThinkPad R32 の起動画面で表示された警告とエラー案内

この無線 LAN カードの PH12127-B も ThinkPad R32 へ設置することができませんでした。やはり Mini-PCI の無線 LAN カードの設置は出来ないようです。残念ながら他の機種へ取り付けたいと思います。

FreeBSD Asterisk 1.8.32.3_2 へアップデート

FreeBSD の ports へ Asterisk のアップデート(1.8.32.3_1 から 1.8.32.3_2 へ)が到着していました。

今回のアップデートはリビジョン番号が若干向上しただけのもののように見えますが、保留音(Music on Hold)に MP3 プレーヤに対応するなど保留音関係に機能が追加されていました。以下にビルドオプションの画像を掲載していますが、+マークのある部分が新規追加の機能です。

Asterisk 1.8.32.3_2 のビルドオプション 1ページ目
Asterisk 1.8.32.3_2 のビルドオプション 2ページ目

以下はパッケージからのメッセージです。
".asterisk.makeopts" が存在していると、ビルドオプションとして処理されるそうです。
その他メニューコマンドの取り扱いの説明があります。

===>>> pkg-message for asterisk18-1.8.32.3_2
###########################################################################

  This port supports custom Asterisk configurations using a *user-supplied*
  menuselect.makeopt file.

  This feature is of most value for users that want to disable or override
  default functionality that they dont want or need, particular in space
  and/or resource constrained, or embedded environments.

  If a file named ".asterisk.makeopts" is found in the ports files/
  directory, its contents will be used to configure Asterisk at the
  post-configure stage.

  If the file is *not* found, the port will default to a 'normal' Asterisk
  menuselect configuration, and only execute menuselect commands according
  to what port OPTIONS the user has selected.

  The format of this file is the same as the output of a standard
  `make menuselect` command, as per standard build instructions for
  Asterisk.

  NOTE: The contents of this file *MUST* be syntactically and semantically
       valid, as the port does *NOT* perform validation of this file.

        In particular, ensure that all Asterisk options have their
        dependencies met, using the corresponding port OPTIONS dependencies.

  The `menuselect --check-deps` command can be used to verify the
  configuration

  The following related documentation resources are also available:

    * https://wiki.asterisk.org/wiki/display/AST/Using+Menuselect+to+Select+Asterisk+Options
    * http://www.asteriskdocs.org/en/3rd_Edition/asterisk-book-html-chunk/installing_base_configuration.html#Installing_id293213

################################################################################

Buffalo WLI2-TX1-G54 の CFE バックアップ(失敗)

先日 WBR-G54 と一緒に入手していた WLI2-TX1-G54 を分解して、CFE のバックアップを行なってみました。

今回 JTAG でフラッシュメモリのバックアップを試みた WLI2-TX1-G54 です。

分解作業

分解作業は先日の WLI2-TX1-AMG54 と同じ手順で行いました。筐体の構造は全く一緒でした。アンテナの固定のためかホットボンドを使っているのを発見しました。
Buffalo WLI2-TX1-AMG54 を分解
http://near-unix.blogspot.jp/2015/08/buffalo-wli2-tx1-amg54.html

WLI2-TX1-G54 の筐体を半分に分割したところです。

ボードを観察

ボードは WLA-G54C と同じ BCM4702 が使用されていました。

WLI2-TX1-G54 のボードの様子です。
プロセッサに BCM4702 が使用されていました。

JTAG の端子を取り出す抵抗器のパッドを観察するとそこには 4.7KΩ の抵抗器が存在していました。また抵抗器の反対側はアースではなく 3.3V へプルアップされていました。少し改良?されていました!

R314〜R317の抵抗器が JTAG 用信号が届いているところです。

JTAG 用ピンヘッダ

JTAG 用のピンヘッダを小基盤へハンダ付けした後、この小基盤とボード上の JTAG 端子をリード線で接続しました。WLA-G54C の JTAG 端子を設置した時の記事を参考にしました。
Buffalo WLA-G54C へ JTAG アクセス
http://near-unix.blogspot.jp/2015/05/buffalo-wla-g54c-jtag.html

JTAG 端子へリード線をハンダ付けしたところです。
青:TMS
緑:TCK
橙:TDI
茶:TDO
小基盤にピンヘッダをハンダ付けしています。

JTAG でフラッシュメモリのバックアップ

早速 JTAG でフラッシュメモリの中の CFE のバックアップを開始しました。最初にバッファタイプの WIGGLER ケーブルで行いました。

WIGGLER ケーブルで接続しているところです。

とりあえずプローブ動作をさせてみました。/noemw /nocwd のオプションがなければプローブ動作も出来ない状況でした。なおこのオプションを設定した後は、ボードの電源を投入したままの状態でプローブ動作を繰り返しても動作しました。
# ./tjtag3 -probeonly /cable:wiggler /nocwd /noemw

================================================
 EJTAG Debrick Utility v3.0.2.1 Tornado-MOD
================================================

Detected IR chain length = 5
Number of device(s) = 1

IDCODE for device 1 is 0x0471017F

Probing bus ... Done

Instruction Length set to 5

CPU Chip ID: 00000100011100010000000101111111 (0471017F)
*** Found a Broadcom BCM4702 Rev 1 CPU chip ***

    - EJTAG IMPCODE ....... : 00000000100000000000100100001000 (00800908)
    - EJTAG Version ....... : 1 or 2.0
    - EJTAG DMA Support ... : Yes
    - EJTAG Implementation flags: R4k MIPS32

Intial value of Control register is 0000000C
Intial value of status register is  00000077
01110111 (00000077)

Status bit 7 Busy Inverted pin 11 = 1
Status bit 6 *Ack          pin 10 = 1
Status bit 5 Paper-out     pin 12 = 1
Status bit 4 Select        pin 13 = 1
Status bit 3 *Error        pin 15 = 0
* means low = true, e.g., *Error

VCC connected
values of Control register after init 0x0000000C
value of status register after init   0x00000077
system reset complete

Issuing Processor / Peripheral Reset ... Done
Enabling Memory Writes ... Skipped
Halting Processor ... ... Done
Init PrAcc ... Skipped
Clearing Watchdog ... Skipped


Chip ID a800
Chip Rev 11
Package Options f
Number of Cores 15
DMA Read Addr = 18000000  Data = (FFFBA800)ERROR ON READ
Core Revision 47
Core Type 8800
Core Vendor ID fffb0000
Flash Type 0
Flash Type = FLASH_NONE
Flash bus is 8 bits
Dest is bits 0
Flash is byteswapped 0
Endian Type is LE 0
PLL Type 00038000
Enter Flash Probe

Probing Flash at (Flash Window: 0x1fc00000) ...
Done

Flash Vendor ID: 00000000000000000000000010001001 (00000089)
Flash Device ID: 00000000000000000000000000010110 (00000016)
*** Found a Intel 28F320J3 2Mx16       (4MB) Flash Chip ***

    - Flash Chip Window Start .... : 1FC00000
    - Flash Chip Window Length ... : 00400000
    - Selected Area Start ........ : 00000000
    - Selected Area Length ....... : 00000000



 *** REQUESTED OPERATION IS COMPLETE ***


プローブ動作をさせてボードが安定したと思われる状態で、CFE のバックアップを四回行なって md5 のハッシュ値を取得してみたところ、全てのハッシュ値が異なっており、バックアップするごとにデータが異なっていました。
82bd833200984aa42cbac5437e5dfef1  CFE.BIN.SAVED_20150830_221823
2591443a219dc4bd19c899794f63d55b  CFE.BIN.SAVED_20150830_222254
d80483554955069c8b1c893328259d4d  CFE.BIN.SAVED_20150830_222731
b0c868af14f9a2ea80563a1c57e4ee49  CFE.BIN.SAVED_20150830_223318

そこで抵抗器で構成した DLC5 タイプのケーブルを使ってバックアップを試みました。これも WIGGLER ケーブルと同じようにバックアップデータが異なっていました。
1e4c82cf384c4fd79b1230234943e3d9  CFE.BIN.SAVED_20150830_224846
d7594b914a9787519ec1f4935ba29b43  CFE.BIN.SAVED_20150830_225524
da5b9cc35b82e7dc8dfecd6ac4623512  CFE.BIN.SAVED_20150830_230031
fbf046cf5d9651933e91ddbe1c3a6fa2  CFE.BIN.SAVED_20150830_230516

上記のようなグダグダな結果となりました。どうも BCM4702 が使用されているボードで JTAG 動作は難しいようです。

このような状況でしたので、CFE のみならずフラッシュメモリ全体のバックアップも中止しました。

2015年8月30日日曜日

Buffalo WLA-G54 へ WBR-G54 の CFE 書き込み

昨日フラッシュメモリのバックアップを行ったバッファロー WBR-G54 の CFE を USB 加工に失敗した WLA-G54 へ書き込みを試みました。

なお今回の書き込みにおいて、フラッシュメモリとシステムメモリ(SDRAM)は、もともとボード上に搭載されていたものに戻してあります。また JTAG 端子のところへ追加していたプルアップ抵抗器も除去しました。JTAG 動作が成功した WBR-G54 の状態に出来るだけ近づけて作業をしました。

WLA-G54 のフラッシュメモリへデータを JTAG 経由で書き込んでいるところです。

フラッシュメモリへ書き込みできませんでした

結論から先に述べますと、CFE への書き込みもフラッシュメモリ全体の書き込みも試みましたが、途中で JTAG 動作が停止してしまいました。結果書き込みできませんでした。CFE の書き込みでは 16% の同じ場所で停止していました。フラッシュメモリ全体の時も CFE の書き込みで停止した場所と思われるところで停止しました。どうも書き込みを停止させる何かの要因があるようです。

また JTAG 動作については、WBR-G54 のフラッシュメモリのバックアップで発見した赤い LED が四回点滅することを繰り返す動作ですが、この WLA-G54 では発生しませんでした。この WLA-G54 ではフラッシュメモリのデータが消去されているのでバッファローオリジナルのファームウェアが動作していないため、無線LANカードを撤去していても赤い LED が点滅しないようです。

そのため JTAG 動作方法としては、ボードの電源を投入すると同時に JTAG を操作しているパソコンから JTAG コマンドを実行させることを行いました。まずプローブ動作を行なって、ボード情報が表示された後、しばらくして再度プローブ動作をさせましたが、全て途中でフリーズしてしまいます。安定して JTAG 動作が出来ない状態なのです。

上記のフラッシュメモリへのデータ書き込みもプローブ動作をした後、書き込みを行ったのではなく、電源投入時に直ぐに書き込み動作をさせていました。何度行なっても前方部分は上手く書き込みを行うのですが、だんだんと書き込みが遅くなって、やがて停止する状態です。

ここまでくると、他のボード上でフラッシュメモリを書き込んだ後、WLA-G54 にフラッシュメモリを戻す方法しか手段がないかもしれません。

[考察]

今回の WBR-G54 と WLA-G54 の JTAG によるフラッシュメモリのバックアップと書き込みを行なっていて気になったことが一つあります。それはフラッシュメモリ上のブートコードのバックアップについてです。

この WBR-G54 と WLA-G54 の両者とも 4MB のトップ・ブート(TopB)のフラッシュメモリです。フラッシュメモリのゼロ番地ではなく、 4MB の最後の部分にブートコードが収容される形式(最後尾のフラッシュメモリのブロックが小さく区分けされている)となっています。フラッシュメモリ全体をバックアップしていたときに観察していた感じでは最後尾には "FFFF" ばかりの NONE 状態のデータが詰まっていました。このフラッシュメモリの形式に係わらずブートコードはゼロ番地から始まる部分に存在するのでしょうか? WLA-G54 が起動しなくなったのは NVRAM を JTAG で消去した後からということを考えると NVRAM の最後尾にはブートコードが存在していて、このブートコードが消去されたことから動作しなくなったとも考えられます。もちろん起動に必要なパラメータが NVRAM に存在していて、このパラメータを失ったことによって起動できなかった可能性もあります。

他の多くの無線LANルータでは、ゼロ番地側のフラッシュメモリのブロックの区画が小さく設定されているボトム・ブート(BotB)のフラッシュメモリが採用されていることもあり、トップ・ブート(TopB)のフラッシュメモリの取り扱いがよく解りません。

2015年8月29日土曜日

Buffalo WBR-G54 のフラッシュメモリのバックアップ

分解掃除も終わり、JTAG 用のピンヘッダを取り付けた WBR-G54 のフラッシュメモリのバックアップを行いました。

新事実(無線LANルータの職業人や愛好家にとっては常識なのかも・・・)をいくつか発見して、どうも正しくフラッシュメモリの内容をバックアップ出来た模様です。しかしまだ出来たとは断言できません。

以下は実際に行った作業と考察の記録です。

WIGGLER ケーブルで通常のバックアップ

今まで通りにバッファタイプの WIGGLER ケーブルにて WBR-G54 のフラッシュメモリの CFE の部分だけをバックアップしてみました。

WIGGLER ケーブルでフラッシュメモリのバックアップを行なっているところです。

JTAG の操作は、操作するパソコンに JTAG のコマンドをリターンキーを押すだけの状態にしておいて、ボードの電源を投入すると同時にパソコンのリターンキーを押して、JTAG コマンドを実行させます。JTAG 動作が直ぐに停止するなど、上手く JTAG コマンドが実行出来なかったときには、繰り返して同様の操作を繰り返します。
------- プローブ動作 ----------
# ./tjtag3 -probeonly /cable:wiggler

================================================
 EJTAG Debrick Utility v3.0.2.1 Tornado-MOD
================================================

Detected IR chain length = 5
Number of device(s) = 1

IDCODE for device 1 is 0x0471017F

Probing bus ... Done

Instruction Length set to 5

CPU Chip ID: 00000100011100010000000101111111 (0471017F)
*** Found a Broadcom BCM4702 Rev 1 CPU chip ***

    - EJTAG IMPCODE ....... : 00000000100000000000100100001000 (00800908)
    - EJTAG Version ....... : 1 or 2.0
    - EJTAG DMA Support ... : Yes
    - EJTAG Implementation flags: R4k MIPS32

Intial value of Control register is 0000000C
Intial value of status register is  000000F7
11110111 (000000F7)

Status bit 7 Busy Inverted pin 11 = 0
Status bit 6 *Ack          pin 10 = 1
Status bit 5 Paper-out     pin 12 = 1
Status bit 4 Select        pin 13 = 1
Status bit 3 *Error        pin 15 = 0
* means low = true, e.g., *Error

VCC connected
values of Control register after init 0x0000000C
value of status register after init   0x000000F7
system reset complete

Issuing Processor / Peripheral Reset ... Done
Enabling Memory Writes ... Done
Halting Processor ... ... Done
Init PrAcc ... Skipped
Clearing Watchdog ... Done


Chip ID 0
Chip Rev 0
Package Options 0
Number of Cores 0
Core Revision 15
Core Type 0
Core Vendor ID 0
Flash Type 0
Flash Type = FLASH_NONE
Flash bus is 8 bits
Dest is bits 0
DMA Read Addr = 18000128  Data = (00000000)ERROR ON READ
Flash is byteswapped 0
Endian Type is LE 0
PLL Type 00000000
Enter Flash Probe

Probing Flash at (Flash Window: 0x1fc00000) ...
Done

Flash Vendor ID: 00000000000000000000000000100000 (00000020)
Flash Device ID: 00000000000000000010001011001010 (000022CA)
*** Found a ST 29w320DT 2Mx16 TopB     (4MB) Flash Chip ***

    - Flash Chip Window Start .... : 1FC00000
    - Flash Chip Window Length ... : 00400000
    - Selected Area Start ........ : 00000000
    - Selected Area Length ....... : 00000000



 *** REQUESTED OPERATION IS COMPLETE ***

四回フラッシュメモリのバックアップを行なってみましたが、二回だけ同じデータとなりました。WLA-G54 の時と同じような状況です。
8676a327a6e4285933e44212924642fe  CFE.BIN.SAVED_20150829_153416
99efda3f23780918712232d3942ceb36  CFE.BIN.SAVED_20150829_152828
99efda3f23780918712232d3942ceb36  CFE.BIN.SAVED_20150829_153913
bea3764ae315b955c7c91e874bf39b8a  CFE.BIN.SAVED_20150829_154836

抵抗値を大きくした DLC5 ケーブルでバックアップ

抵抗器で構成された DLC5 ケーブルでバックアップも試みました。しかし今まで DLC5 ケーブルに改造を加えました。今までは 100Ω の抵抗器を使用していましたが、TDI, TMS, TCK の 100Ω の抵抗器へ直列に 2.2KΩ の抵抗器を接続して 2.3KΩ の抵抗器として使用してみました。
このような処置をした理由は、パソコンのプリンタ・ポートから出力される 5 ボルトの電圧が 100Ω の抵抗器を経由して BCM4702 へ印加されているとき、BCM4702 の入力端子を保護するためのクリッパーダイオードを経由して BCM4702 の電源(3.3 ボルト? か 1.8 ボルト?)に余分な電流が流れこんでしまうことになります。この電流によって、もしかして BCM4702 の電源が揺れる現象が発生した場合、内部動作に異常を引き起こす可能性がありました。そこでこの電流を少なくするために抵抗値を大きくしてみました。あまり大きな値にすると、ボード側のプルアップ抵抗器の影響でロー・レベルに十分に下がり切らない可能性や波形が鈍るなどの副作用もあります。とりあえず手持ちにあった 2.2KΩ の抵抗器を接続してみました。

DLC5 タイプのケーブルへ 2.2KΩ の抵抗器を接続したところです。

フラッシュメモリのバックアップの値の MD5 のハッシュ値を比較したところ、やはりバラバラでした。
d85cdcdd07437be8b0e7bf62b40fd48e  CFE.BIN.SAVED_20150829_165250
99efda3f23780918712232d3942ceb36  CFE.BIN.SAVED_20150829_165721
7777d35292eb40162d38bd5df1272f31  CFE.BIN.SAVED_20150829_170130
99efda3f23780918712232d3942ceb36  CFE.BIN.SAVED_20150829_171108

JTAG モードへ移行したサイン?

ここで一つ発見しました。フラッシュメモリをバックアップしている途中、LED1 と LED2 の赤いランプが四回点滅を繰り返しては、少し休んで再び四回点滅することを繰り返しているのです。これが JTAG モードへ移行していることのサインである可能性がありました。
[2015-08-30 追記]
この四回の赤い LED の点滅は、無線LANカードがないことを警告するもののようです。JTAG ケーブルを接続しないで、写真のように無線LANカードを取り外した状態で起動させると同様の動作をします。このことから、正常に JTAG でフラッシュメモリのバックアップが出来たときには、ファームウェアが動作しているようです。

JTAG でフラッシュメモリをバックアップしている途中、赤い LED 二個が四回点滅することを繰り返していました。

TDO 用にトランジスタ・バッファを追加

上記の TDI, TMS, TCK へ 2.2KΩ の抵抗器を追加したDLC5 タイプのケーブルへトランジスタを二個組み合わせたバッファ回路を追加しました。

今回追加した二個のトランジスタによるバッファ回路です。
図面が手書きでごめんなさい。
昔、家電製品から取り出していたトランジスタ(2SC458)を流用しました。
今では見かけることのない台形パッケージの製品です。
二個のトランジスタで構成したバッファ回路です。

この目的は、スレッショルド・レベルをシリコントランジスタの 0.6 ボルトとすることで、TDO 信号が少しでも上昇するとハイ・レベルと見做してしまうものです。BCM4702 の電源は 3.3 ボルトの他に 1.8 ボルトも使用されているということで、TDO の信号のハイ・レベルがパソコンのプリンタポートで知覚できる 2.5 ボルトのスレッショルド・レベルを下回っている可能性があります。そこでこのトランジスタのバッファ回路を使って、かならず 3.3 ボルトまで上昇するようにしてみました。ただこのトランジスタのバッファ回路によって信号の遅延が発生するなどの副作用も考えらますが、とりあえず試しに行なってみました。

トランジスタのバッファ回路付きの DLC5 ケーブルでフラッシュメモリのバックアップを行なっているところです。

フラッシュメモリの CFE のバックアップは大成功です。四回バックアップを行なって三回同じデータが得られました。今回のバックアップで特に注意したことは、最初のバックアップを行った後、ボードの電源を切らずにそのままバックアップを繰り返したことです。上記の JTAG モードを示していると思われる LED の点滅を確認をしながらバックアップを継続した結果です。どうも JTAG モードに入った直後は、データが乱れる可能性があるようです。
bea3764ae315b955c7c91e874bf39b8a  CFE.BIN.SAVED_20150829_181028
99efda3f23780918712232d3942ceb36  CFE.BIN.SAVED_20150829_181409
99efda3f23780918712232d3942ceb36  CFE.BIN.SAVED_20150829_181804
99efda3f23780918712232d3942ceb36  CFE.BIN.SAVED_20150829_182218
-- 青色のハッシュ値のデータが正しいデータのようです。--

フラッシュメモリ全体をバックアップ

そこでフラッシュメモリ全体を JTAG モードに入った状態からバックアップを開始してみました。4MB のフラッシュメモリ全体をバックアップするのに一時間ほど時間が必要です。何度も繰り返すことができませんが、何とか三回繰り返しました。三つのデータとも同じハッシュ値でした。
7ac19ccfe041e015d66b7aef862e75ef  WHOLEFLASH.BIN.SAVED_20150829_184641
7ac19ccfe041e015d66b7aef862e75ef  WHOLEFLASH.BIN.SAVED_20150829_194705
7ac19ccfe041e015d66b7aef862e75ef  WHOLEFLASH.BIN.SAVED_20150829_210051

再度通常の DLC5 タイプのケーブルでバックアップ

JTAG モードへの移行で正常にバックアップ出来るとなると、改造した DLC5 ケーブルではなく、通常の DLC5 ケーブルではどうなるか?・・・を再度 CFE をバックアップして確認してみました。なんと!四回測定しましたが、同じハッシュ値となり、安定してバックアップが出来ていました。
99efda3f23780918712232d3942ceb36  CFE.BIN.SAVED_20150829_221641
99efda3f23780918712232d3942ceb36  CFE.BIN.SAVED_20150829_221301
99efda3f23780918712232d3942ceb36  CFE.BIN.SAVED_20150829_222156
99efda3f23780918712232d3942ceb36  CFE.BIN.SAVED_20150829_222537

結果

JTAG モードに移行したことを確認して、フラッシュメモリのバックアップを行う必要があります。
通常の DLC5 タイプのケーブルでバックアップができました。おそらく JTAG モードへ正しく移行した後であれば WIGGLER ケーブルでも動作するものと思われます。

手順

以下の手順で正しくバックアップが出来ました。

1. ボードの電源投入と同時にプローブ動作をさせる。
   -- これで JTAG モードへ移行します。[2015-08-30 削除]
2. しばらくすると二個の赤い LED が四回点滅することを繰り返すのを確認する。
3. 念の為、再度プローブ動作をさせる。
4. バックアップ動作をさせる。
   -- 動作中も赤い LED が四回点滅していれば正常にバックアップをしている。
   -- 途中で赤い LED が四回点滅がしなくなった場合、異常の可能性があります。

その他注意点として、JTAG を動作させた直後の "Init PrAcc ... Skipped" のところで一時的に停止して再開するようです。正しく JTAG モードになっていないときには、ここでフリーズします。この場合、ボードの電源を切って、最初からやり直しとなります。

Buffalo WBR-G54 の分解掃除

バッファローの WBR-G54 を分解して掃除をしました。

今まで類似の筐体を幾つも分解しているので、分解作業に手間取ることはありませんでした。

筐体のフロントパネルにあったフェルトペンでの落書きは、アルコールで殆ど綺麗に消すことができました。角度と光の反射によって、落書きがあった場所はまだ判りますが、言われなければ気づかない程度でした。

そして筐体のプラスチック部品は、いつものようにレンジ周り用の強力アルカリ性洗剤で水洗いしました。以前の所有者さんは喫煙者だったようで、タバコの汚れも臭いもすっきり落とせました。

水洗中の筐体部品です。

内部のボードは、水分で湿らせた刷毛で丁寧にホコリを拭きとりました。イーサネット用ソケットの内部もかなりホコリが溜まっていましたが、ここも小さな筆を使って綺麗に掃除しました。

WBR-G54 のボードです。
WLA-G54 になかった WAN 用のソケットが存在しています。

Mini-PCI ソケットに刺さっていた無線 LAN カード(WLI-MPCI-G54)も取り出して、綺麗に掃除をしておきました。本機では無線 LAN カードとアンテナを繋ぐケーブルの途中にフェライトコアが挿入されており、さらにこのフェライトコアが接着剤で無線 LAN カードへ固定されていました。

ボードから取り外した無線 LAN カード(WLI-MPCI-G54)です。

この WBR-G54 でも JTAG でフラッシュメモリのバックアップを行う予定ですので、JTAG 用のピンヘッダを取り付けました。以前の WLA-G54 でもそうでしたが、スルーホールのハンダが簡単に除去出来たので助かりました。

JTAG 用のランド(スルーホール)からハンダを抜いたところです。
ピンヘッダをハンダ付けしたところです。

この後、JTAG によってフラッシュメモリのバックアップを行いたいと思っています。しかし、今まで BCM4702 が搭載された無線 LAN ルータでフラッシュメモリのバックアップが正しく行われていないため、かなり心配です。

Debian Iceweasel が 40.0.3 へアップデート

mozilla.debian.net で配布されている Iceweasel (Firefox) の最新版が 40.0 から 40.0.3 へアップデートしました。

Iceweasel 40.0.3 へのアップデート通知
Iceweasel 40.0.3 のクレジット表示

2015年8月28日金曜日

Buffalo WBR-G54 を入手

インターネット・オークションにて、バッファローの WBR-G54 やイーサネット・コンバータの WLI2-TX1-G54 、 WLI2-TX1-AG54 を詰め合わせセットとして入手しました。WBR-G54 の前面パネルの汚れが痛々しいのですが、安価で入手出来た理由ですので我慢のしどころです。

今回入手した WBR-G54,WLI2-TX1-G54,WLI2-TX1-AG54 です。

WBR-G54 は、以前 USB ポートを設置しようと計画をして、システムメモリの拡張作業を行なっている途中で動作不良となってしまった WLA-G54 のリベンジ用に入手しました。WLA-G54 へ USB ポートを設置することは一応諦めていません。しばらく放置はしていますが、心の中では継続中です(笑)。

私の場合、BCM4702 を搭載している無線 LAN ルータのフラッシュメモリへ JTAG アクセスが上手く出来ていない状態です。今後 JTAG によるフラッシュメモリのバックアップや書き込みが正常に出来るようになったとき、この WBR-G54 の CFE データなどを流用して WLA-G54 を復活させようと目論んでいます。もちろん WLA-G54 の CFE もバックアップしてありますが、JTAG によるバックアップに問題がある(バックアップする度にデータが異なっている)ことに気づかない状態でバックアップしたものですので、全然信頼性がありません。

また一緒に入手した合計三台のイーサネット・コンバータは、中身が BCM4702 が搭載されたものだと思われますので、こちらも BCM4702 のフラッシュメモリが JTAG で正常にバックアップ出来るようになってから遊びに使ってみたいと思っています。

今回入手した WBR-G54,WLI2-TX1-G54,WLI2-TX1-AG54 の背面です。


2015年8月27日木曜日

Buffalo WAPS-HP-AM54G54 の wl0 が通信出来ない問題

Broadcom の wl ドライバへ入れ替えていた WAPS-HP-AM54G54 の OpenWrt Attitude Adjustment 12.09 ですが、その後原因を探っていましたが、どうも暗号化の部分で通信ができなくなっているようです。

実験4. 暗号化なしの設定

無線 LAN デバイスの wl0 と wl1 の暗号化を「なし(none)」にしたところ、wl0 も wl1 も通信しました。
wl0 -- 暗号化なし === 通信可能
wl1 -- 暗号化なし === 通信可能

実験5. 片方の無線 LAN デバイスの暗号化を「なし」に設定

wl0 -- 暗号化なし === 通信可能
wl1 -- 暗号化あり === 通信可能

wl0 -- 暗号化あり === 通信不能
wl1 -- 暗号化なし === 通信可能
wl0 が暗号化なしの場合、5GHz 帯の IEEE 802.11 a で通信が出来ました。

以上のことから、wl0 と認識される無線LANデバイスとの通信は暗号化の過程によって通信ができなくなっている模様です。

ここまで判明しました。解決策は見つかっていません。

2015年8月26日水曜日

Buffalo WAPS-HP-AM54G54 の OpenWrt 化が少し進展

OpenWrt の各種バージョンのファームウェアをインストールして動作確認をしていた バッファロー WAPS-HP-AM54G54 ですが、その後少し進展がありました。

昨日まで Barrier Breaker 14.07 をインストールしていましたが、5GHz 帯の無線 LAN 通信が出来ない問題がありますが、他のバージョンよりも問題の少ない Attitude Adjustment 12.09 へインストールし直しました。この Attitude Adjustment 12.09 の動作において、各種の設定ファイルの情報を取得して Barrier Breaker 14.07 の問題点対策にあてようと考えています。

さてこの Attitude Adjustment 12.09 での問題点は、二つある無線 LAN デバイスのうち 5GHz 帯のものが、SSID などの電波を発射しているにも係わらずアクセス出来ないことです。問題点の切り分けのために幾つかの実験を行いました。そこで判明したことは次の通りです。

実験1. 二つの無線 LAN デバイスのソケットを入れ替えてみる。

元々の状態は、奥側に 5GHz 帯の WLI2-MPCI-AM54 が刺さっていて、手前側に 2.4GHz 帯の WLI2-MPCI-G54 が刺さっていました。これを入れ替えてみたところ、5GHz 帯と 2.4GHz 帯のアクセス 出来る・出来ない が入れ替わってしまいました。

当初はこの WLI2-MPCI-AM54 をドライバが動作させることが出来ないものと思っていました。
しかし wl ドライバによって 5GHz 帯の通信ができることが判明しました。
当初はこの WLI2-MPCI-G54 だけが通信できるものと思っていました。
ソケットの場所を変更すると通信出来なくなってしまいました。

これで判明したことが、5GHz 帯のデバイスの WLI2-MPCI-AM54 は wl ドライバで動作することと、ソケットの位置でデバイス名も入れ替わり wl1 と認識されるデバイスは通信が可能で、wl0 と認識されるデバイスは通信が不可能ということでした。

WAPS-HP-AM54G54 の二つの無線LANデバイスを入れ替えたところです。
上側のソケットは wl0、下側のソケットは wl1 と認識されます。
なおソケットの位置と LED の表示はハードウェア的に接続されていることも判明しました。

実験2. 無線 LAN デバイスを一つだけ挿してみる。

二つの無線LANデバイスを二箇所のソケットへそれぞれ挿してみては、動作確認をしてみました。合計四つの組み合わせとなりますが、そのどれもが wl0 と認識されて通信が出来ませんでした。

これで判明したことは、一つの無線 LAN デバイスの場合でも wl0 として認識された場合には通信ができないことでした。

実験3. 手動でもう一つ無線 LAN デバイスの設定を追加する。

/etc/config/wireless の設定ファイルを直接編集して、wl0wl1 の他に wl2 という仮想の無線 LAN デバイスを追加してみました。すると、今度は wl0 も wl1 も通信ができなくなってしまいました。三つ目の無線LANデバイスは現実には存在していませんので、wl2 が本当に通信できるかどうかは不明です。

この実験で判明したことは、wl0 と認識された無線 LAN デバイスだけが通信出来ないのではなく、無線 LAN デバイスの番号の一番大きいもの一つだけが通信出来る模様です。

三つ目の無線LANデバイスを手動で追加した状態です。

ここまでで判明したこと

以上の三つの実験から、OpenWrt の内部でのネットワークの繋がりが上手く出来ていないようです。ネットワーク設定の /etc/config/network と無線 LAN 設定の /etc/config/wireless を見直してみましたが、間違えがあるようには思われませんでした。内部のネットワークの接続状況を確認する brctl コマンドで確認をしても二つの無線LANデバイス(wl0, wl1)と LAN ポート(eth0)は繋がっているようです。
# brctl show

現在のところ、ここで行き詰っています(笑)

おまけで嬉しい発見(BCM4309 チップも動作)

WAPS-HP-AM54G54 の Mini-PCI ソケットへ BCM4309 のチップが搭載された2.4GHz 帯と 5GHz 帯を選択する無線LANカードを挿してみました。すると wl ドライバによって BCM4324 と認識されて 2.4GHz 帯と 5GHz 帯の両方が動作することが判明しました。やはりチップメーカが作るドライバ(wl)は、対応が断然良いようです。

BCM4309 チップが搭載されており、wl ドライバによって BCM4324 と認識された無線 LAN カードです。


FreeBSD 9.3 の p24 (AMD64, OpenSSH, PKG) アップデート

FreeBSD 9.3 へ p24 アップデート(3個)が到着しました。AMD64 プロセッサの IRET コマンドの動作異常対策、OpenSSH の子プロセスによる権限上書き問題対策、PKG の署名タイプに NONE 設定問題の対策だそうです。
FreeBSD-SA-15:21.amd64
https://www.freebsd.org/security/advisories/FreeBSD-SA-15:21.amd64.asc
FreeBSD-SA-15:22.openssh
https://www.freebsd.org/security/advisories/FreeBSD-SA-15:22.openssh.asc
FreeBSD-EN-15:15.pkg
https://www.freebsd.org/security/advisories/FreeBSD-EN-15:15.pkg.asc

FreeBSD 10 系のみのアップデート
FreeBSD-EN-15:14.ixgbe
https://www.freebsd.org/security/advisories/FreeBSD-EN-15:14.ixgbe.asc

/usr/src/UPDATING の内容

20150825:       p24     FreeBSD-SA-15:21.amd64
                        FreeBSD-SA-15:22.openssh
                        FreeBSD-EN-15:15.pkg

Fix local privilege escalation in IRET handler. [SA-15:21]

Fix OpenSSH multiple vulnerabilities. [SA-15:22]

Fix insufficient check of unsupported pkg(7) signature methods.
[EN-15:15]

ソースツリーの更新

subversion でソースツリーを更新しました。
# svn update /usr/src
Updating '/usr/src':
G    /usr/src/UPDATING
U    /usr/src/sys/amd64/amd64/exception.S
U    /usr/src/sys/amd64/amd64/machdep.c
U    /usr/src/sys/amd64/amd64/trap.c
U    /usr/src/sys/conf/newvers.sh
U    /usr/src/crypto/openssh/monitor.c
U    /usr/src/crypto/openssh/monitor_wrap.c
U    /usr/src/crypto/openssh/mux.c
U    /usr/src/usr.sbin/pkg/pkg.c
Updated to revision 287149.

ユーザランドとカーネルの再ビルド

今回のアップデートでは、ユーザランドとカーネルの再ビルド(再構築)が必要です。
# cd /usr/src
# make buildworld
# make buildkernel KERNCONF=MYKERNEL

ユーザランドとカーネルのインストール

# make installkernel
# make installworld

マシンの再起動

# reboot

2015年8月25日火曜日

Buffalo WAPS-HP-AM54G54 へ OpenWrt をインストールしてハマる

先日、分解掃除とフラッシュメモリのバックアップなどを行ったバッファロー WAPS-HP-AM54G54 へ OpenWrt のファームウェアをインストールしてみました。

OpenWrt Attitude Adjustment 12.09

OpenWrt Attitude Adjustment 12.09 をインストールした場合、二つ搭載されている Mini-PCI の無線 LAN デバイスのどちらもが 2.4GHz 帯の IEEE 802.11 b/g デバイスとして認識されてしまいます。本機には 8MB のフラッシュメモリが搭載されているため、ExtRoot 化することもなく Broadcom の wl ドライバをインストールすることができます。この wl ドライバでは WLI2-MPCI-AM54 を 2.4GHz 帯と 5GHz 帯の共用デバイスとして認識していましたが、何故か通信が出来ない状態でした。


なお wl ドライバ上では二つの無線LANデバイスは次のように認識されていました。
WLI2-MPCI-AM54
 wl0: Broadcom BCM4319 802.11 Wireless Controller 5.10.56.27

WLI2-MPCI-G54
 wl1: Broadcom BCM4318 802.11 Wireless Controller 5.10.56.27

OpenWrt Barrier Breaker 14.07

OpenWrt Barrier Breaker 14.07 もインストールしてみました。何と! LAN ポートから外に通信が出来なく無くなってしまいました。起動時の CFE では、ちゃんと LAN ポートと外部への通信ができるため、ファームウェアの再インストールは可能であったため、この異常事態から脱出することが出来ました。

当初は何かインストール上の問題があるのかと思って何度か再インストールを行なってみましたが、 LAN ポートの通信が出来ない症状は改善されませんでした。

が、しかし・・・一度 Attitude Adjustment 12.09 へ戻した後、再度 Barrier Breaker 14.07 をインストールしたとき、LAN ポートが開通していました。そして各種設定を行うことが出来たのですが、再起動を行ったところ再度 LAN ポートが不通となってしまいました。

この一度 LAN ポートが開通していたことから /etc/config/network の LAN ポート関連の設定を見直しをしては、再起動を繰り返していますが、未だに LAN ポートが設定出来ない状態となっています。なお一度 LAN ポートが開通した Attitude Adjustment 12.09 へ戻した後、再度 Barrier Breaker 14.07 をインストールしてみましたが、LAN ポートは開通しませんでした(涙)。


OpenWrt Chaos Calmer 15.05 RC3

OpenWrt Chaos Calmer 15.05 RC3 もインストールしてみました。これも Barrier Breaker 14.07 と同様に LAN ポートと外部の通信が出来ない状態となっていました。


今後の予定

フラッシュメモリ(8MB)やシステムメモリ(64MB)に余裕がある WAPS-HP-AM54G54 には OpenWrt の新しいバージョンに更新し続けたいと考えています。そこで何とか LAN ポートが不通となっている原因を突き止めて対策が出来ないものかと考えています。どうしても対策が発見できないようでしたら、5GHz 帯の無線LANデバイスの部分に問題がありますが、システムが稼動している Attitude Adjustment 12.09 でインストールを進めたいと思っています。