家に転がっていた D-Link の DSM-232(メディアプレーヤー)が気になって、ちょっと本格的に手を出してみた。結果的に GPL ソースの解析から U-Boot / Linux の移植、フラッシュの解析まで、思ったより長い道のりになったのでメモしておく。
DSM-232 ってどんな機器か
D-Link が出していたネットワークメディアプレーヤーで、中身は Celestial Semiconductor(後に Cavium に買収された)の CNC1800L という SoC。コードネームは “Tiga Mini”。
- CPU: ARM1176JZF-S(ARMv6)
- RAM: 256MB
- フラッシュ: SPI(ブートローダ用の小容量)+ NAND(カーネル・rootfs 用、512MB)
- 映像出力: HDMI + コンポジット
- 無線: SDIO 接続の Wi-Fi
要するに今のラズパイより一世代以上前の、いかにも「2012年ごろの STB チップ」という構成。D-Link は GPL 義務のとおりソース一式(DSM-232_A1_GPL_FWv1.02.00.rar)を公開していて、これが今回の出発点になった。
最初にやったこと: GPL ソースの素読み
落としてきた tarball を展開すると、Buildroot ベースのビルドシステム一式と、SoC 固有パッチ(Linux 2.6.32 に当てる BSP パッチが 8.8MB、U-Boot 2011.06 向けパッチが 7.2MB)が出てくる。古い。しかし古いなりに中身は素直で、
- UART は 8250 互換 ×2(
0x801F1000/0x801F2000) - 割り込みコントローラは DesignWare の APB ICTL と同一レジスタ配置
- NAND コントローラは DaVinci 系に近い構成で、512バイトごとに 1bit Hamming の HW ECC
- SPI は DesignWare SSI だが、レジスタアクセスが 16bit 固定という癖がある
といった情報がベンダードライバから拾えた。レジスタマップさえ分かれば、現行の mainline に機能を足していくのは意外と見通しが立つ。
Linux 7.2 と U-Boot 2026.07 への移植
せっかく解析したので、現行の mainline に DT ベースで最小構成を足してみた。
Linux 側は arch/arm/mach-celestial にマシンコードを置くだけで、残りは全部 Device Tree で表現する方式。割り込みは mainline の snps,dw-apb-ictl がそのまま使えたのが地味に嬉しかった(自作しなくていい部分は自作しない)。タイマだけはベンダー独自の構成だったので新規ドライバを書いた。UART が出て起動ログが流れるところまでは確認済み。
U-Boot 側も同じ方針で、ARM1176 向けの最小ボードサポートを追加。ビルドは通り、バイナリサイズも純正ファームのブートローダ領域に収まるサイズに収めた。
ここまではビルド確認のみで、実機ではまだ動かしていない。
フラッシュ(SPI / NAND)対応
純正ドライバの ECC がどう見ても独自仕様だったので、これも現行の標準 API に揃える形で書き直した。具体的には:
- 「旧(レガシー)」= SoC 内蔵の HW 1bit Hamming。既存の NAND 内容やブートローダと互換性がある
- 「新(標準)」= Linux/U-Boot の汎用ソフトウェア ECC(BCH)。標準的だが既存データとは非互換
の二本立てで用意した。せっかく標準 Hamming に寄せられないかと符号の総当たり検証もしてみたが、ビット位置のマッピングが違って互換性なし。ここは素直に「両方作って選べるようにする」のが落としどころだった。
フラッシュダンプの解析
ここで実機の SPI / NAND ダンプを提供してもらえたので、構造解析に進んだ。わかったこと:
- NAND 上の U-Boot イメージは 2 重化されていて、冗長構成になっている(片方が壊れても起動できるようにという設計)
- 末尾に 256 バイトの署名が付いていて、GPL 付属の「insecure」鍵では検証できなかった
- U-Boot のバイナリ内に RSA-2048 / PKCS#1.5 の署名検証に関する文字列が多数出てくる
つまりこの機種、ミニローダーの段階でセキュアブートがかかっている可能性が高い。D-Link 側が独自鍵でサインしていると見られる。
ここは正直なところ、この先に踏み込む(署名検証そのものを解析・無効化する)のは、仮に自分の持っている機体が対象だとしても、同じ仕組みを持つ他の機体にも効いてしまう類の作業なので手を止めた。セキュアブートを崩さずに独自カーネルを載せる別の経路(署名済み U-Boot から chainload する、など)を探すのが筋が良さそうというのが現時点の結論。
今のところのまとめ
- SoC・ブートチェーンの全体像は解析できた
- mainline Linux 7.2 / U-Boot 2026.07 への最小ポーティングはビルドまで完了
- SPI/NAND のドライバも新旧 2 方式で用意した
- 実機ではセキュアブートの壁があることが判明し、そこから先は方針転換が必要
という進捗。古い STB チップの解析はネット上の情報も少なく地道な作業だったが、GPL ソースが素直に読める分、見積もりより楽に進んだ部分も多かった。セキュアブートの壁は想定内というか、むしろここまで素直に進んでいたので「どこかに引っかかるだろうな」と思っていた通りの場所で引っかかった感じ。続きはまた進んだら書く。