# Jetson Orin NXを出先から書き込んだ記録｜USB/IPがブートROMで失敗した理由とWSL2での解決｜株式会社テクノスフィア

> 出張先からVPN越しにUSB/IPでJetson Orin NXを書き込もうとして、ブートROMへの転送のタイムアウトで3回失敗。手元のWSL2に切り替え、USBの横取りとRNDIS非対応をNCM化で乗り越え、約4分で書き込みを終えるまでの実践記録を解説します。

URL: https://technosphere.co.jp/blog/jetson-remote-flash-usbip-wsl2

** 目次
1. 出先でJetsonの書き込みが必要になった
2. USB/IPで事務所へ飛ばす作戦と、その壁
3. 手元のWSL2で書き込む
4. WSL2で踏んだ2つの落とし穴
5. 結果と、この手順の限界
6. よくある質問（FAQ）
7. まとめ
   ** 本記事について

本記事は、当社がエッジAI機器の設置準備のなかで実際に行った作業の記録です。お客様や案件を特定できる情報、社内のネットワーク情報は載せていません。また、ここで紹介するWSL2での書き込みは**NVIDIAの公式手順ではありません**。試す場合は、ご自身の環境で十分に確認してください。

## 出先でJetsonの書き込みが必要になった

 NVIDIAのJetson Orin NXは、カメラ映像の解析などに使う小型のエッジAIコンピュータです。新しいOSを入れるには、Jetsonを**リカバリモード**（電源投入時に専用ボタンを押して入る、書き込み待ちの状態）で起動し、USBでつないだPCから書き込み（flash）します。

 今回は設置の前日に、出張先でOSを入れ直す必要が出ました。手元にあるのはWindowsのノートPCとJetsonだけです。書き込み用の環境（Ubuntuサーバー上のツール一式）は遠く離れた事務所にあり、ノートPCからはVPNで事務所につながっていました。

## USB/IPで事務所へ飛ばす作戦と、その壁  （図: ノートPCから遠くのサーバーまで山や雲を越えて伸びるケーブルの途中に砂時計があり、先端のエッジコンピュータの手前で光が途切れているイメージイラスト）

 最初に考えたのは**USB/IP**です。USB機器をネットワーク越しに別のコンピュータへ接続したように見せる仕組みで、Windowsではusbipd-winで使えます。ノートPCに挿したJetsonを事務所のサーバーへ渡せば、事務所の書き込み環境がそのまま使えるはずでした。

 接続そのものはうまくいき、サーバーからリカバリモードのJetsonが見えました。ところが書き込みを始めると、ブートROM（Jetsonの内蔵ROMにある、最初に動く書き込み受付プログラム）へ最初のデータを送る段階で、毎回タイムアウトします。

```
Sending bct_br
ERROR: might be timeout in USB write.
Error: Return value 3
```

| 回線 | 事務所までの往復時間（平均） | 結果 |
| **モバイル回線（LTE）** | 約49ms | 最初の転送でタイムアウト（2回） |
| **Wi-Fi回線** | 約25ms | 同じ箇所でタイムアウト（1回） |

 回線を良くしても、止まる場所は変わりませんでした。ブートROMとのやり取りは、USBが手元に直結されている前提の短い待ち時間で動いていると考えられます。**数十msの往復遅延が乗る遠隔USBでは、この段階を越えられない**と判断し、作戦を切り替えました。なお、通常起動したJetsonのシリアルコンソールや、USBネットワークでの通信は、同じUSB/IPで問題なく使えていました。

## 手元のWSL2で書き込む  （図: ノートPCの画面の中の透明なコンテナから短いケーブルでエッジコンピュータへ光が流れ込み、ロボットが親指を立てているイメージイラスト）

 次の作戦は、ノートPCのWSL2（Windows上でLinuxを動かす仕組み）で書き込むことです。usbipd-winは、同じPCの中のWSL2へUSB機器を渡すこともできます。ネットワークを経由しないので、遅延の問題は起きません。

 課題は、書き込みツールを動かすLinux環境を手元にどう用意するかでした。WSL2の中から外部へのダウンロードが、VPN経由では途中で止まってしまい、パッケージを入れられなかったためです。そこで、事務所のサーバーで使っていた**書き込み用のDockerイメージ（ツール一式が入ったUbuntu環境）を書き出し、そのままWSL2のディストリビューションとして取り込みました**。

```
# 事務所のサーバーで書き出す
cid=$(docker create <イメージ>)
docker export $cid | gzip -1 \
  > l4t.tar.gz

# ノートPCで取り込む
wsl --import l4t C:\wsl\l4t `
  l4t.tar.gz
```

- **転送は圧縮後で約556MB**——パッケージを1つずつ入れるより、通信も手間も少なく済みました
- **ARM向けバイナリの実行設定を手で登録**——WSL2では、x86上でARM64のプログラムを動かすQEMUの登録（binfmt）が自動ではされず、rootfsの準備スクリプトが失敗したためです
- **既存の環境には手を入れない**——取り込んだディストリビューションは書き込み専用にし、普段使いのWSL環境とは分けました

## WSL2で踏んだ2つの落とし穴  （図: ロボットがケーブルの途中の合わないパズルピースを、ぴったり合うピースに差し替えて光を通しているイメージイラスト）

### 落とし穴1: 仮想化ソフトのUSBサービスがJetsonを横取りしていた

 WSL2に切り替えてから、Jetsonが「数秒〜数分でUSBから消える」ように見える症状が続きました。最初は電源の不足を疑いましたが、AC電源での給電でした。原因は、そのPCに入っていた**仮想化ソフトのUSB管理サービスが、つなぎ直されたJetsonを自分のUSB機器として取り込んでいた**ことでした。書き込みの途中でJetsonは何度も再起動し、そのたびにUSB機器として認識し直されます。その瞬間を横取りされていたのです。サービスを止めると、症状は消えました。

### 落とし穴2: WSL2のカーネルにRNDISのドライバが無かった

 現在のJetsonの書き込みは、まず書き込み用の小さなLinux（initrd）をJetsonで起動し、PCとUSBネットワークでつないでからストレージへ書き込みます。このUSBネットワークは**RNDIS**というMicrosoft由来の方式ですが、今回のWSL2のカーネルには、RNDISを受けるドライバが入っていませんでした。Jetsonは起動しているのに、PC側からは通信できず、「起動待ち」のまま止まります。

 一方で、標準規格の**CDC-NCM**方式のドライバはWSL2にもありました。Jetsonのカーネルにも同じ方式のモジュールがあります。そこで、書き込みツールに含まれる「Jetson側でUSBネットワークを作る設定」と「PC側でJetsonを探す条件」を、RNDISからNCMに書き換えました。
- **Jetson側の設定**——USBガジェットの機能を rndis から ncm に変更
- **PC側の検出条件**——RNDISに加えてNCMの名前でも、Jetsonのネットワークを見つけられるように変更
- **書き換えは、その場限り**——元のファイルは残し、作業後に戻せるようにしました

 あわせて、書き込みを2段階に分けました。1回目の失敗ログにボードの種類やリビジョンが残っていたので、それを指定して**Jetsonをつながずに書き込みイメージだけを先に作り**（--no-flash）、Jetsonがリカバリモードで現れたら書き込みだけを実行する（--flash-only）形です。USBがつながっている時間を短くでき、つなぎ直しの影響も受けにくくなりました。

## 結果と、この手順の限界

 2つの落とし穴を越えると、書き込みは順調に進みました。ストレージ（NVMe）とブートローダー領域への書き込みは**約4分**で終わり、ツールは成功を返しました。その後、Jetsonの電源を入れ直してもネットワーク設定やSSHが自動で戻ることを確かめ、設置先のネットワーク設定も入れて、翌日の設置に向けた準備を終えました。
| 試した方法 | 結果 | 決め手 |
| **USB/IPで事務所のサーバーへ** | 失敗（3回） | ブートROMへの最初の転送が、往復遅延でタイムアウト |
| **手元のWSL2（そのまま）** | 失敗 | USBの横取りと、RNDISのドライバ不足 |
| **手元のWSL2（対策後）** | 成功（約4分） | サービス停止、NCMへの変更、2段階の書き込み |

 ただし、これは**「急ぎで、この場をしのぐ」ための手順**です。NVIDIAが案内しているのはx86のUbuntuホストからの書き込みで、WSL2やスクリプトの書き換えは公式の手順ではありません。将来のバージョンで、同じ書き換えが通用する保証もありません。時間に余裕がある場合や、量産・保守で繰り返す作業では、公式の構成で書き込むことをおすすめします。

## よくある質問（FAQ）   Q. USB/IPとは何ですか？ A. USB機器をネットワーク越しに別のコンピュータへ接続したように見せる仕組みです。Windowsではusbipd-winで使えます。シリアル変換やライセンスドングルなら実用的ですが、遅延に厳しいブートROMへの書き込みには向かないことが、今回の検証でわかりました。 Q. JetsonはWSL2から書き込めるのですか？ A. 当社の環境では書き込めました。ただし本記事の手順は、NVIDIAの公式手順ではありません。公式に案内されているのはx86のUbuntuホストからの書き込みで、スクリプトの書き換えも当社がその場限りで行ったものです。可能であれば公式の構成で書き込むことをおすすめします。 Q. 出先でJetsonを書き込む前に、何を準備すればよいですか？ A. 書き込みツール一式を、手元のPCにあらかじめ用意しておくことが一番効きます。あわせて、仮想化ソフトのUSBサービスがUSB機器を横取りしないか、WSL2のカーネルに必要なUSBドライバがあるかを、事前に確認しておくと安心です。

## まとめ

 出先からUSB/IPで事務所のサーバーへJetsonを渡す方法は、ブートROMへの最初の転送で3回とも止まりました。手元のWSL2に書き込み環境を取り込み、USBの横取りとRNDISのドライバ不足を解消すると、書き込みは約4分で終わりました。

 持ち帰れる学びは、**「遠隔USBは、通常の通信には使えても、書き込みのような遅延に厳しい処理には向かない」**ことと、**「つながらない時は、経路の途中で誰がUSBやドライバを握っているかを疑う」**ことです。どちらも、事前に確認しておけば現地で慌てずに済みます。

 当社では、Jetsonをはじめとするエッジ機器のセットアップや、現場への設置、遠隔保守の設計までお手伝いしています。「出先や現場で機器の書き込み・更新が必要になる運用をどう組むか」といった段階のご相談も歓迎です。