JP2004178575A - 電子機器および該電子機器にファイルをダウンロードするためのシステムならびに方法 - Google Patents

Abstract

【課題】通常オペレーション中に完全なプロトコルスタックコードによって動作可能なＵＳＢインタフェースを備えたモデムなどのような電子機器において、そのブートオペレーション中にＵＳＢインタフェースを介してこのような電子機器のソフトウェアをアップグレード可能にする。
【解決手段】ブートコードはインタフェース用の軽量プロトコルスタックコードを有しており、この軽量プロトコルスタックコードは、完全なプロトコルスタックのレイヤのサブセットから成る。
【選択図】図５

Description

本発明は、１つの完全なプロトコルスタックコードにより通常オペレーション中に動作可能なインタフェースを備え、フラッシュメモリなどのような不揮発性メモリが設けられていて、該不揮発性メモリには機器ブート用のコードが含まれているモデムなどのような電子機器、および該電子機器にファイルをダウンロードするためのシステム、ならびに該電子機器のメモリ部分にファイルをダウンロードする方法に関する。

現在、電子機器用のソフトウェアのアップデータやバグフィックス等をユーザに配布するためにいくつかのメカニズムが存在する。第１の可能性として挙げられるのは、機器がアップグレードを必要としている場所まで技術者が出向いて、更新の必要なメモリセクションを置き換えることである。

いっそう効率的なフル稼働モード中のソフトウェアアップグレードもすでに知られており、これはたとえば汎用シリアルバス（Universal Serial Bus, USB）を介して行うことができる。１つの公知の方法によればソフトウェアアップグレードはフル稼働中のソフトウェアにおいて行われ、その際、新たなソフトウェアは最初にＳＤＲＡＭにダウンロードされ、ついでフラッシュメモリにダウンロードされる。しかしこれには、フラッシュメモリへのダウンロード中に何らかのエラーが発生したら機器が動作不能状態になってしまうというリスクが伴う。

さらに、イーサネットインタフェースを介してブートオペレーション中にファイルをダウンロードすることもすでに知られている。この解決手段によればフラッシュメモリにブートコードが含まれており、このコードは典型的にはフラッシュメモリの最上部におかれ、そこにおいてフラッシュプログラミングツールによってプログラミングされる。このブートコードは機器の基板がスイッチオンされるとスタートし、イーサネットインタフェースを介してファイルをダウンロードするために用いられる。この目的でブートコードには、イーサネットポートを介してBOOTPリクエストを送信するためのブートストラッププロトコル Bootstrap protocol BOOTPと、イーサネットポートを介してファイルをダウンロードするための簡易ファイル転送プロトコル trivial file transfer protocol TFTP が含まれている。この種の機器にＵＳＢを設けることができ、ここではＵＳＢプロトコルスタックコードはブートコードにではなく典型的にはオペレーションソフトウェア内に存在する。その理由はこのＵＳＢコードのサイズが、たとえば４ＭＢという典型的なサイズをもつフラッシュメモリ内に格納するには大きすぎることによる。このためブートオペレーション中にＵＳＢを介してソフトウェアをアップデートするのは不可能である。

本発明の課題は、ブートオペレーション中にいっそう幅広いアップグレードを行わせる装置およびシステムならびに方法を提供することにある。

本発明によればこの課題は、電子機器のソフトウェアはそのブートオペレーション中にアップグレード可能であり、ブートコードは前記インタフェースのための軽量プロトコルスタックコードを有しており、該軽量プロトコルスタックは完全なプロトコルスタックのレイヤのサブセットから成ることを特徴とする電子機器により解決される。

さらに上述の別の課題は、少なくとも１つのコンピュータにＵＳＢインタフェースが設けられていて、１つまたは複数のコンピュータにファイルを格納するステップと、少なくとも汎用シリアルバス（ＵＳＢ）を介して前記電子機器を１つまたは複数のコンピュータに接続するステップと、完全なＵＳＢプロトコルスタックに比べて低減されたＵＳＢプロトコルスタックを利用して、少なくとも１つのブートリクエストを前記電子機器から前記１つまたは複数のコンピュータへ前記ＵＳＢインタフェースを介して送信するステップと、前記１つまたは複数のコンピュータから前記電子機器へ少なくとも１つのブートリプライを送信するステップと、前記電子機器から前記１つまたは複数のコンピュータのうち１つのコンピュータにファイル転送リクエストを送信するステップと、前記格納されたファイルを前記１つのコンピュータから前記電子機器へ送信するステップを有することを特徴とする、ＵＳＢコネクションを備えた電子機器のメモリ部分にファイルをダウンロードする方法により解決される。

電子機器の通常オペレーション中、インタフェースのすべてのオペレーションをコントロールするために、およびこのインタフェースに関連するすべてのプロトコルを処理するために、典型的にはオペレーションソフトウェア中に完全なプロトコルスタックコードが設けられている。典型的なインタフェースはたとえばUSB, USB2またはFirewireなどである。いっそう幅広いアップグレードオプションを提供する目的で本発明による電子機器は、この機器のソフトウェアがこの種のインタフェースを介してブートオペレーション中にもアップグレードが可能であるように構成されている。

完全なプロトコルスタックコードは通例、大量のメモリを占有するものであり、フラッシュメモリ内のブートコードには適していない。電子機器のコストの点ではフラッシュメモリのサイズを制限するのが望ましい。したがって本発明の別の目的として挙げられるのは、不揮発性メモリ内の対応するブートコードサイズを小さく維持することである。この目的は、ブートオペレーション中にインタフェースを処理するための軽量プロトコルスタックコードだけをもつブートコードを使用することによって達成される。

本発明の別の実施形態によれば、ブートコードは前記のインタフェースを検出するためのコントロールコードと、このインタフェースを介して送受信を行うためのプロトコル処理コードとを有している。この種のブートコードによってこのインタフェースを介してデータを送信できるようになり、このデータを電子機器のソフトウェアアップグレードのために機器のメモリに書き込むことができる。

本発明の有利な実施形態によればインタフェースはＵＳＢインタフェースである。完全なＵＳＢプロトコルスタックというのはかなり大きいプロトコルスタックであり、これは典型的にはオペレーションソフトウェア中に設けられているのに対し、ブートコードは軽量プロトコルスタックだけを使用することから小さく維持されており、つまりメモリサイズが低減される。

さらに本発明の別の目的は、通常オペレーション中に完全なプロトコルスタックコードによって動作可能なＵＳＢインタフェースを備えたモデムなどのような電子機器において、そのブートオペレーション中にＵＳＢインタフェースを介してこのような電子機器のソフトウェアをアップグレード可能にすることである。

このため本発明の別の観点によれば前述のブートコードには、前記の完全なプロトコルスタックコードのイーサネットからＵＳＢへのマッピングパートが含まれている。このパートは、ワイドエリアネットワーク（ＷＡＮ）を介した通信に必要とされるＡＡＬ５／ＡＴＭ／ＵＳＢ（ATM: asynchronous transfer mode; AAL: ATM adaption layer）マッピングをサポートしていない。換言すれば、いくつかのレイヤが取り除かれている。しかしながらこのパートによって、少なくともＵＳＢポートにおいて電子機器と接続されたコンピュータなどの適切な機器へＢＯＯＴＰリクエストを首尾よく伝送可能にするために必要とされるカプセル化が保証される。さらに詳しくは、ＢＯＯＴＰ、ユーザデータグラムプロトコル（ＵＤＰ）ならびにインターネットプロトコル（ＩＰ）がブートオペレーション中に利用され、これによってＢＯＯＴＰ／ＵＤＰ／ＩＰをイーサネットにカプセル化することができる。しかもＵＳＢを介したこのイーサネットプロトコルスタックは完全なスタックと比べて軽量なプロトコルスタックであり、その結果としてブートコードがいっそう小さくなる。

したがって本発明の別の観点によれば、ワイドエリアネットワーク（ＷＡＮ）を介した通信のための完全なＵＳＢプロトコルスタックコードが第２のメモリに含まれている。このコードは、通常オペレーション中にワイドエリアネットワーク（ＷＡＮ）を介した通信に必要とされるＡＡＬ５／ＡＴＭ／ＵＳＢマッピングをサポートする。

有利な実施形態によればモデムはさらにイーサネットインタフェースを有しており、この場合、ブートコードはブートオペレーション中にイーサネットを介して送受信するためのコードを有している。これによって、ＵＳＢインタフェースを介したまたはイーサネットインタフェースを介したモデムのソフトウェアアップグレードが考慮される。

本発明はさらに、前述の実施形態のいずれかに従って電子機器にファイルをダウンロードするためのシステムに関する。このシステムには、前述の電子機器と前述のインタフェース用のドライバを備えたコンピュータとが設けられていて、このコンピュータは前述のインタフェースを介して電子機器と接続されており、リモートのコンピュータには、電子機器と通信するためのおよびダウンロードすべきファイルを供給するための実行可能なプログラムコードが含まれている。ＵＳＢインタフェースの場合、ＵＳＢドライバはコンピュータ内部のＵＳＢハードウェアをコントロールし、コンピュータ上のソフトウェアはプログラムインタフェースセットを介してこのドライバと通信することができる。

実行可能なプログラムは一般にそれ自体ＰＣにおいてアップグレードウィザードプログラムを成しており、これは一連のダイアログボックスを用いた手順を通してステップを追ってユーザをガイドするプログラムである。

電子機器がＵＳＢインタフェースとイーサネットインタフェースを有しているならば、アップグレードウィザードプログラムはＵＳＢポートあるいはイーサネットポートの双方を介してアップグレード可能である。

ＵＳＢホスト通常はコンピュータとＵＳＢデバイスとの間の基本通信要素はパイプとエンドポイント（ＥＰ）である。エンドポイントは、ＵＳＢホストとＵＳＢデバイス内部のいくつかの機能との間の論理的な伝送経路である。エンドポイントは通常、単方向のみでデータを送信するために存在しており、それらはパイプなどのようにいっそう先進的な通信経路のために使用される。

本発明によるシステムの１つの特有の実施形態によれば、送信すべきフレームをＵＳＢデバイスへおよびそこから送信できるようにするため、ＵＳＢインタフェースのエンドポイント（ＥＰ）４および５においてそれぞれコネクションが確立される。エンドポイントは所定のプロトコルの使用と結びつけられており、ＥＰ４，ＥＰ５の選択はブートオペレーション中に使用される軽量プロトコルに関連づけられる。

このコネクションを可能にするためブートコードは、コントロールに使用されるＥＰ０と、バルクモードにおけるソフトウェアダウンロードインタフェースとして使用されるＥＰ４と、バルクモードにおける確認応答インタフェースとして用いられるＥＰ５をサポートしている。他のエンドポイントはブートオペレーション中は使用不能状態におかれ、ＥＰ４とＥＰ５以外のエンドポイントにおけるすべてのトラフィックは除かれる。

本発明はさらに、ＵＳＢコネクションを備えた電子機器のメモリ部分にファイルをダウンロードするための方法に関し、この方法は以下のステップから成る。すなわち、
−１つまたは複数のコンピュータにファイルを格納するステップ、ここで少なくとも１つのコンピュータにはＵＳＢインタフェースが設けられている；
−前記電子機器を少なくとも汎用シリアルバス（ＵＳＢ）を介して１つまたは複数のコンピュータに接続するステップ；
−完全なＵＳＢプロトコルスタックと比べて低減されたＵＳＢプロトコルスタックを使用し、ＵＳＢインタフェースを介して前記電子機器から１つまたは複数のコンピュータに少なくとも１つのリクエストを送信するステップ；
−前記１つまたは複数のコンピュータから前記電子機器へ少なくとも１つのブートリプライを送信するステップ；
−前記電子機器から前記１つまたは複数のコンピュータのうちの１つにファイル転送リクエストを送信するステップ；
−格納されたファイルを前記１つのコンピュータから前記電子機器へ送信するステップ。

この方法の有利な実施形態によれば、上述のブートリクエストとブートリプライはＢＯＯＴＰプロトコルを使用する。また、上述のファイル転送リクエストおよび格納されたファイルの送信を、簡易ファイル転送プロトコル（ＴＦＴＰ）を使用して行うと有利である。ファイルが電子機器のメモリパートに格納されたならば、ダウンロードされたファイルの形式に応じてそのファイルからブートするのが有利である。

この方法における１つの特有の実施形態によれば、電子機器は少なくとも１つのコンピュータとイーサネットを介しても接続されている。この場合、ブートリクエストはＵＳＢインタフェースとイーサネットインタフェースの双方に送信される。最初の可能性によれば、最初にブートリプライを受け取ったインタフェースを介してファイル転送が確立される。他の可能性によれば、ＵＳＢインタフェースを介して接続されたコンピュータから受け取ったブートリプライとイーサネットインタフェースを介して接続されたコンピュータから受け取ったブートリプライの双方が、電子機器によって監視されることになる。たとえば転送すべきファイルの重要性あるいはバージョンなどに依存して、電子機器は複数のコンピュータのうちのいずれかに優先権を与えることができる。

本発明のさらに別の特徴や利点は、図面を参照しながら以下で説明する本発明の有利な実施形態の説明に示されている。

図１には、本発明によるモデム１の主要ハードウェアコンポーネントの概観が描かれている。このハードウェアアーキテクチャによって、電話回線と１つまたは複数のコンピュータとの間のリンクが形成される。電話回線インタフェース３は典型的にはＤＳＬターミネーションインタフェースであって、ここではＲＪ−１１コネクタが使用される。

ＡＤＳＬモデム１はさらに第１のブロック２を有しており、これにはアナログフロントエンドと、アナログ回線インタフェースのターミネーションおよびディジタルデータをメインコントローラ４からアナログバンドパス信号に変換するための特定用途向け集積回路（ＡＳＩＣ）が含まれていて、このＡＳＩＣのことをＡＤＳＬ ＡＳＩＣと称する。アナログフロントエンドモジュールは、既存電話サービス網（ＰＯＴＳ）信号をフィルタリング除去しＡＤＳＬ信号の通過を許可するハイパスフィルタと、アップストリーム信号とダウンストリーム信号とを分離するため２線から４線へまたはその逆への変換を実行するハイブリッド回路たとえば受動回路網と、アップストリームラインドライバとダウンストリームレシーバフィルタとによって構成されている。ＡＤＳＬ ＡＳＩＣによって、アナログ／ディジタル変換（Ａ／Ｄ）およびディジタル／アナログ変換（Ｄ／Ａ）が行われる。メインコントローラ４は基本的にディジタルＡＤＳＬモデムＡＳＩＣ、イーサネットＡＴＭアダプタおよびマイクロプロセッサを有している。

ディジタルＡＤＳＬモデムＡＳＩＣにはＤＭＴ（digital multitone）変調の手法を用いる信号変復調器が含まれており、これによってイーサネットまたはＵＳＢインタフェースから到来する信号が変調されてそれらがＡＤＳＬ，ＡＳＩＣに供給され、さらにその逆のことが行われる。

コントローラには、シンクロナス・ダイナミック・ランダムアクセスメモリ５（ＳＤＲＡＭ）とフラッシュメモリすなわち電気的にプログラミング可能なリードオンリメモリ（ＥＰＲＯＭ）６から成るメモリプールが付属しており、このリードオンリメモリ６はブロック単位で消去および再プログラミング可能な不揮発性メモリである。フラッシュＥＰＲＯＭのサイズは典型的には２ＭＢであって８ＭＢまで拡張可能である。典型的には８ＭＢのサイズであるＳＤＲＡＭは、たとえば３２ｂｉｔ幅のバスを介してメインコントローラ４と通信を行う。

イーサネットインタフェース７は専用インタフェースを介してコントローラと接続されている。イーサネットインタフェース７は典型的には、ＲＪ−４５コネクタを備えた１０／１００ＢａｓｅＴインタフェースである。

専用のＵＳＢ集積回路を含むＵＳＢインタフェース１１は、たとえば１６ｂｉｔ幅のデータバスと１ｂｉｔ幅のアドレスバスから成るパラレルインタフェースを介して、メインコントローラ４と接続されている。

この機器にはさらに、内部電源８と接続された標準電源プラグ９が設けられている。内部電源８の出力側から複数の電圧が供給され、たとえば１２Ｖと３．３Ｖと１．８Ｖが供給される。これらの給電電圧によって、ハードウェアコンポーネントのために必要とされる電源が供給される。

さらにこの機器には通常、ＬＥＤ（発光ダイオード）などのような複数の視覚的インジケータが設けられており、これによって機器の種々のハードウェアの振る舞いが表示される。モデムの通常オペレーション中、機器は以下のように動作する。電話回線からＡＤＳＬ信号が受信され、ＡＡＬ５でカプセル化された所定のバーチャルチャネルとバーチャルパスの組み合わせをもつ標準ＡＴＭセルに変換される。これらの組み合わせによって、到来トラフィックがオペレーションおよびメンテナンストラフィックから成りオンボードプロセッサによりルーティングされ処理されるのか、あるいはそのままＵＳＢまたはイーサネットへ送られるべきブリッジされたイーサネットフレームから成るのか、あるいはＵＳＢまたはイーサネットへ転送されるルーティングされたＩＰパケットから成るのかが決定される。

図２には、モデムシステムをブートするためのプロセスを示すフローチャートが描かれている。ボードがパワーオンされると、コントローラは内部ＲＯＭからの実行コードをスタートさせ、それに応じてフラッシュメモリにおけるブートコードの開始アドレスにジャンプし、このアドレスはボードサポートパッケージ（ＢＳＰ）のエントリポイントである。そこでＢＳＰが実行開始される。

まだ実行されていないＢＳＰのパートはブートコードとともにＳＤＲＡＭにコピーされ、これにはグローバル変数および初期化されたデータが続く。プログラムカウンタはＳＤＲＡＭ内のコードにセットされ、コントローラは実行を開始する。ＢＳＰがその初期化を完了すると、プログラムはブートコードのエントリポイントにジャンプする。

ついでＢＯＯＴＰリクエストメッセージが送信され、ＢＯＯＴＰレスポンスタイマが実行を開始する。このメッセージの内容および使用されるプロトコルスタックについては、図３および図４を参照しながら詳しく説明する。その後、この機器はリプライ待ち状態となる。

タイムアウトした場合または無効なリプライである場合、矢印１６で示されているように新たなリクエストが送信される。この再送信の回数はたとえば、タイムアウトまたは無効なリプライの場合の再試行回数を指定するリクエストパラメータに依存させることができる。有効なリプライメッセージが受信された場合にはＩＰアドレスがセットされ、チェックブロック１７で示されているようにこのリプライメッセージの内容がチェックされる。

リプライメッセージにファイル名が含まれている場合にはプロセスにおける以下のステップは、簡易ファイル転送プロトコル Trivial File Transter Protocol (TFTP) を利用したファイルのダウンロードである。つまりデータパケットがホストコンピュータからＳＤＲＡＭに伝送され、これについては以下で詳しく説明する。

ダウンロードごとに、転送されたファイルのヘッダがチェックされる。ファイルはたとえば以下のフォーマットをもつ：
表１

表１のすべての行は４ｂｙｔｅである。ファイルヘッダの最初の４ｂｙｔｅはファイルフォーマット識別子を表し、これにはたとえばＢＬＩ１つまりBoot Loader Image Version 1 が含まれている。

ファイルの宛先を後続の４ｂｙｔｅにおくことができ、これにはＳＤＲＡＭまたはフラッシュメモリ内の宛先開始アドレスが含まれている。

オプションとしてタグコードが設けられており、これにはあらゆるタイプの情報が含まれていて、これによりたとえばファイルからブートするために用いられるアドレス、ファイルデータのトータルサイズ等が指定される。

さらに図２を参照すると参照符号２２で示されているようにデータは宛先に従い、ＳＤＲＡＭ内に残されるかまたはフラッシュメモリに格納される。後者の場合、フラッシュ照合パターンを含む宛先領域が消去され、データが書き込まれる。ついで書き込まれたデータがチェックされ、これはたとえば送信ファイルのファイルヘッダ中に存在する巡回冗長検査（Cyclic Redundancy Check, CRC）の再計算および比較により行われる（表１参照）。モデムにより生成されたチェックデータが送信されたチェックデータと同じであれば、フラッシュ照合パターンが書き込まれる。それらが同じでなければ、線２４で示されているようにリブートが実行される。

問い合わせブロック２５で規定されているこのプロセスの次のステップは、ＢＯＯＴＰリプライメッセージ中のフラグに依存する。このオプションは、ブロック２６で表されているような所定のファイルエントリポイントでブートするためのものであり、あるいは問い合わせ２７においてボードサポートパッケージ（Board Support Package, BSP）が存在しているならば、このパッケージから第２のブートを実行するためであり、あるいはそれが存在していないのであればスタートからリブートさせるためのものである。

なお、上述の説明はプロセス中の主要なステップを表したにすぎないことは自明であり、さらに明らかなように、たいていのオペレーションは個々のモデム形式に依存して所定の回数反復可能なループを使ったタイムアウト方式を用いている。また、いくつかの付加的なテストを実行させてもよい。

図３には、ブートコードで用いられるプロトコルスタックが示されている。これは初期化 Init, 簡易ファイル転送プロトコル Trivial File Transfer Protocol (TFTP), ブートプロトコル Boot Protocol (BOOTP), ユーザデータプロトコル User Data Protocol (UDP), イーサネットコントロールメッセージプロトコル (ICMP), IP (Internet Protocol), アドレス解決プロトコル Address Resolution Protocol (ARP), イーサネット Ethernet, ETH USB （イーサネットをＵＳＢにダイレクトにマッピングさせるプロトコル）によって構成されている。個別のプロトコルのタスクについてはあとで説明する。

図４を参照するとそこには、ブートオペレーション中にファイルがダウンロードされ、いかなるエラーも発生しない場合の、モデムＭとコンピュータＰＣとの間の通信について示す図が示されている。矢印２８で表されているように、まずはじめにＢＯＯＴＰリクエストがモデムからＰＣへ送信される。このメッセージにはＭＡＣ（Medium Access Control）アドレスのような情報、ベンダ固有の情報などが含まれており、これはイーサネットインタフェースとＵＳＢインタフェースの双方へ送信される。

次に図３を参照しながら、このＢＯＯＴＰリクエストのフォーマットがどのようにして整えられるかについて説明する。ＩＮＩＴモジュール３０が初期化されると、まずはじめにＢＯＯＴＰリクエストの最初のフィールドが構築され、それがＢＯＯＴＰモジュール３１に送られ、これによってＭＡＣアドレスなどのような情報を含む完全なＢＯＯＴＰリクエストが合成されることになる。ついでＵＤＰ３３、ＩＰ３９、さらにインタフェースによってはイーサネット３６またはＵＳＢイーサネット３５によって、プロトコルスタックを通過して下がっていくときにそれらのヘッダがＢＯＯＴＰフレームに加えられる。物理層に到達すると、アクティブなインタフェースに従いＵＳＢおよび／またはイーサネットネットワークを介してブロードキャストされる。

ＭＡＣレイヤ３４はイーサネットインタフェースまたはＵＳＢインタフェースへのアクセスをコントロールし、ＩＰアドレスをフレーム伝送に使われる物理アドレスに変換するためにアドレス解決プロトコル（address resolution protocol, ＡＲＰ）３８が用いられる。インターネットコントロールメッセージプロトコル（ＩＣＭＰ）によって、ＩＣＭＰメッセージ送信時の動作異常たとえば輻輳の問題などを考慮することができる。このようなメッセージを受け取ったとき、ＩＰによってその問題が扱われる。

ＢＯＯＴＰリクエストが送信されると、モデムＭはＢＯＯＴＰリプライの待機状態をスタートさせる。有効なＢＯＯＴＰリプライには要求された情報が含まれていなければ、それはたとえばモデムに割り当てられたＩＰアドレス、本発明による実施形態によればＰＣに含まれているＴＦＴＰサーバのＩＰアドレス、ダウンロードすべきファイル名のフルパスなどである。ＢＯＯＴＰリプライは最初はＵＳＢインタフェースから受信され、このＵＳＢインタフェースを介してさらに通信が行われ、これと同じことはイーサネットインタフェースについてもあてはまる。この実施形態によれば、リプライを出すＰＣがまず最初に優先権を獲得する。冒頭ですでに説明したように、最新のアップグレードファイルが格納されているＰＣに対して優先権を与えるなど、他のインプリメンテーションが可能である。

矢印２９および矢印４０によって表されているのは、モデムが有効なＢＯＯＴＰリプライを受け取ると、モデムによりＴＦＴＰ伝送が初期化され、それによってＴＦＴＰリクエストがＢＯＯＴＰリプライ中で指定されたＩＰアドレスのところにあるＴＦＴＰサーバへ送信されることである。このリクエストには、８１９２ｂｙｔｅのＴＦＴＰブロックサイズに対するオプション・ネゴシエーションも含めることができる。

ついでモデムは第１のデータパケットの到来を待つ。データパケットが到来すると、ファイルヘッダが分析されて、ファイルをフラッシュメモリに格納しその際にまず最初にＳＤＲＡＭにバッファリングすべきか、あるいはＳＤＲＡＭ内の適正なアドレスのところにただちに配置すべきかが決定される。

最初のパケットのデータがＳＤＲＡＭ内に首尾よく配置された後、矢印４２によって示されているように確認応答パケット（acknowledgement packet, ＡＣＫ）がコンピュータへ送信される。これらのステップは最後のパケットを受信するまで繰り返される。

図５には種々のソフトウェアコンポーネントが概略的に描かれており、これは典型的には２ＭＢのサイズをもつフラッシュメモリに格納されている。ブートコード５０は典型的にはフラッシュメモリの最上位の１２８ＫＢを満たしており、これにはＵＳＢコードのイーサネットプロトコル処理パート（ＥＴＨ ＵＳＢ）が含まれている。さらにこの領域は、ＬＥＤやタイマのようないくつかのハードウェアコンポーネントをアクセスするためのボードサポートパッケージ（Board Support Package, BSP）を使用している。フラッシュメモリにはさらに５２のオペレーションソフトウェア、通常のオペレーションを目的としたファイルシステム、およびこのファイルシステムにより使用されるスペースが含まれている。

次に図６を参照すると、そこにはモデムＭのソフトウェアアップグレード中に使用されるプロトコルを表すブロック図が示されており、ここではＵＳＢインタフェース６３またはイーサネットインタフェース６２を介してモデムに接続されたＰＣ上でウィザードが実行される。ＵＳＢインタフェース６３がアクティブであり、かつウィザード６１が開始されると、ＵＳＢドライバに対するコネクションが確立される。モデムＭがＵＳＢインタフェースを介してウィザードにつながると、ウィザードはモデムＭにより送信されたＢＯＯＴＰリクエストを待ち受けようとする。ＥＰ５を介してモデムのＵＳＢインタフェースから到来するＢＯＯＴＰリクエストは、ＵＤＰ／ＩＰ／ＥＴＨ／ＵＳＢフレーム内にカプセル化されている。ＵＳＢドライバ６４はこのフレームを非カプセル化してすなわちカプセルから取り出して、ＵＤＰ／ＩＰ／ＥＴＨフレームを形成し、それに応じてこのフレームがさらに非カプセル化されてウィザード６１に転送される。

その後、ウィザード６１はＢＯＯＴＰリプライをＵＳＢドライバ６４に送信し、これはＵＤＰ／ＩＰ／ＥＴＨにカプセル化されることになる。ついでＵＳＢドライバ６４は受信パケットをＥＰ４を介してＵＳＢデバイスに転送する。

同じようにしてモデムＭはＴＦＴＰリクエストを送信し、これはウィザード６１によって受信され、他方、ウィザード６１はＴＦＴＰを使用してリクエストされたファイルを送信することによりリプライする。モデムＭがイーサネットインタフェースを介してウィザードとつなげられるときも、同様のプロセスが行われる。

次に図７を参照すると、ここではモデムＭはイーサネットインタフェースを介して第１のＰＣ１に接続されており、ＵＳＢインタフェース６８を介して第２のＰＣ２に接続されている。この場合、ウィザード６１は、ＴＦＴＰ転送のために初期化されるインタフェースにソフトウェアをアップロードするだけであり、イーサネットインタフェースとＵＳＢインタフェースの双方にはアップロードしない。

ここで説明し図面に示した実施形態は、特にＰＣベースのオペレーティングシステムに係わるものであるが、本発明はＰＣベースのオペレーティングシステムに限定されるものではなく、本発明をＵＮＩＸシステムやＭａｃｉｎｔｏｓｈシステムによっても利用できるし、あるいはＵＳＢインタフェースを備えた他のいかなるシステムによっても利用できる。これまで１つの特定の実施形態について例示し説明してきたが、本発明は種々の変形実施形態を含むものであり、本発明の範囲は以下の特許請求の範囲に基づき規定されるものである。

本発明によるモデムシステムの主要ハードウェアコンポーネントを示すブロック図である。 本発明の方法に従ってモデムシステムをブートするプロセスを示すフローチャートである。 本発明の１つの実施形態によるシステムのために使用されるプロトコルスタックのブロックダイアグラムである。 本発明の方法に従ったブートオペレーション中のモデムとコンピュータとの間の通信プロセスを示す図である。 本発明によるモデムのフラッシュメモリ内における様々なソフトウェアコンポーネントを示す図である。 本発明による方法を用いＵＳＢを介してソフトウェアアップデートを実行するモデムとコンピュータから成るシステムを示す図である。 本発明によるモデムを示すブロック図であって、このモデムはイーサネットインタフェースを介して第１のＰＣと、ＵＳＢインタフェースを介して第２のＰＣと接続されている。

符号の説明

１ モデム
３ 電話回線インタフェース
４ メインコントローラ
５ シンクロナス・ダイナミック・ランダムアクセスメモリ
６ フラッシュメモリ
７ イーサネットインタフェース
８ 内部電源
９ 標準電源プラグ
１１ ＵＳＢインタフェース

Claims (10)

1. １つの完全なプロトコルスタックコードにより通常オペレーション中に動作可能なインタフェースを備え、不揮発性メモリが設けられていて、該不揮発性メモリには機器ブート用のコードが含まれている電子機器において、
   該電子機器のソフトウェアはそのブートオペレーション中にアップグレード可能であり、
   前記ブートコードは前記インタフェースのための軽量プロトコルスタックコードを有しており、該軽量プロトコルスタックは完全なプロトコルスタックのレイヤのサブセットから成ることを特徴とする電子機器。
2. 前記ブートコードは、前記インタフェース検出用のコントロールコードと、該インタフェースを介した送受信のためのプロトコル処理コードを有する、請求項１記載の電子機器。
3. 前記インタフェースはＵＳＢインタフェースである、請求項１または２記載の電子機器。
4. 前記ブートコードには、前記完全なプロトコルスタックコードについてイーサネットからＵＳＢへのマッピングパートが含まれている、請求項３記載の電子機器。
5. 第２のメモリを備えており、該第２のメモリはワイドエリアネットワーク（WＷＡＮ）を介した通信用の完全なＵＳＢプロトコルスタックコードを有する、請求項３または４記載の電子機器。
6. イーサネットインタフェースと、ブートオペレーション中に該イーサネットインタフェースを介して送受信を行うためのコードが設けられている、請求項１から５のいずれか１項記載の電子機器。
7. 請求項１から６のいずれか１項記載の電子機器にファイルをダウンロードするためのシステムにおいて、
   前記電子機器と前記インタフェース用のドライバを備えたコンピュータとを有しており、
   該コンピュータは前記インタフェースを介して前記電子機器と接続されており、遠隔の前記コンピュータに、前記電子機器と通信するためおよびダウンロードすべきファイルを供給するための実行可能なプログラムが含まれていることを特徴とする、
   電子機器にファイルをダウンロードするためのシステム。
8. 前記インタフェースはＵＳＢインタフェースであり、該ＵＳＢインタフェースのエンドポイント（ＥＰ）４および５各々においてコネクションが確立されて、ＵＳＢデバイスへのフレーム送信およびＵＳＢデバイスからのフレーム送信が許可される、請求項７記載のシステム。
9. ＵＳＢコネクションを備えた電子機器のメモリ部分にファイルをダウンロードする方法において、
   少なくとも１つのコンピュータにＵＳＢインタフェースが設けられていて、１つまたは複数のコンピュータにファイルを格納するステップと、
   少なくとも汎用シリアルバス（ＵＳＢ）を介して前記電子機器を１つまたは複数のコンピュータに接続するステップと、
   完全なＵＳＢプロトコルスタックに比べて低減されたＵＳＢプロトコルスタックを利用して、少なくとも１つのブートリクエストを前記電子機器から前記１つまたは複数のコンピュータへ前記ＵＳＢインタフェースを介して送信するステップと、
   前記１つまたは複数のコンピュータから前記電子機器へ少なくとも１つのブートリプライを送信するステップと、
   前記電子機器から前記１つまたは複数のコンピュータのうち１つのコンピュータにファイル転送リクエストを送信するステップと、
   前記格納されたファイルを前記１つのコンピュータから前記電子機器へ送信するステップを有することを特徴とする、
   ＵＳＢコネクションを備えた電子機器のメモリ部分にファイルをダウンロードする方法。
10. ＵＳＢコネクションとイーサネットコネクションを備えた電子機器のメモリ部分にファイルをダウンロードするための請求項９記載の方法において、
    前記電子機器はイーサネットコネクションを介して少なくとも１つのコンピュータと接続されている、請求項９記載の方法。

Images