このデバイスは、Big-EndianMIPS命令セットを使用して、RTL8197DNチップセットを使用しています。私の調査によると、内部の実際のMIPSコアはレクラのようです(検証する)。
ブート中にWPSを押して同時にリセットします。ブートローダーモードに入ります。ブートローダーは、UARTを介してシンプルなコマンドインターフェイスを提供し、TFTPを介して更新をアップロードできるようにします( ./upload_update.shを参照)。ブートが失敗した場合、ブートローダーは自動的に入力されます(リカバリモードとしても機能します)。
更新がTFTPを介してアップロードされると、アドレス0x80500000でRAMにロードされます。ファイルが適切な更新ファイルの場合、フラッシュは自動的に開始されます。そうしないと、ファイルはRAMにとどまるだけで、FLWコマンドを使用して手動でフラッシュすることができます。
確認された作業コマンド:
デバイスは、ブートローダーメッセージとLinuxシェルを使用してUARTヘッダーを公開します。 38400ボー
ユーザー名:ルートパスワード:Webパネルの管理者パスワードとして構成されているもの(デフォルト:管理者)
すべてが大きなエンディアン。更新ファイルを解析するスクリプトについては./check_update.pyを参照してください。
更新ファイルは、一緒に連結された次のブロックで作成されています。
| オフセット | サイズ | 説明 |
|---|---|---|
| 0 | 4 | ファイルタイプ-https://github.com/jameshilliard/wecb-vz-gpl/blob/master/rtl819x/bootcode/boot/init/rtk.hを参照してください。私たちが持っているデバイスは、カーネルに「cr6c」とrootfsに「r6cr」を使用しているようです(ブートローダーには「ブート」?) |
| 4 | 4 | RAMのロードアドレス(カーネル画像にのみ使用されるようですか?) |
| 8 | 4 | フラッシュメモリのアドレス |
| 12 | 4 | データの長さ |
| 16 | * | データ |
データはチェックサムされています - すべてのバイトの16ビットのビッグエンディアン合計は0x0000でなければなりません(このデバイスにはないWebファイルパーティションをフラッシュしていない限り - その場合、チェックサムは8ビットです)。これは通常、最後に2バイトを追加することで実現されます。
ブートローダーが最初に〜4つのハードコーディングアドレスを最初に見てロードしようとすると、次にフラッシュ全体を検索して署名を検索します。これは、フラッシュレイアウトが異なるデバイスで異なる可能性があることを示しているようです。データには、上記の更新ファイルに同一のチェックサムチェックがあります。
./split_img.shを参照してください
| アドレスを開始します | エンドアドレス | ヘッダ | 説明 |
|---|---|---|---|
| 0x00000000 | 0x00006000 | - | ブートローダーコード |
| 0x00006000 | 0x00008000 | H601(?) | ハードウェア構成(Macアドレスなど) |
| 0x00008000 | 0x00010000 | compds(?) | デフォルトの構成 |
| 0x00010000 | 0x00018000 | compcs(?) | 現在の構成 |
| 0x00018000 | 0x00138000 | CR6Cのヘッダーを更新します | Linuxカーネル、更新ヘッダー形式と同一のヘッダーが付いています |
| 0x00138000 | 0x00327002 | HSQから始まるSquashfsファイルシステムヘッダー | ルートファイルシステム。チェックサム用に最後の2バイトが追加されます。 |
| 0x00327002 | 0x00400000 | - | 0xff 0xff 0xff 0xff ... |