(57)【要約】【課題】不揮発性メモリユニットにおいて、ファームウェアイメージの位置を特定する。【解決手段】ホスト装置１０８は、不揮発性メモリユニット１０１と、ホスト装置１０８に格納され、プロセッサ１０７によって実行されるブートモジュール１０２とを備える。ブートモジュール１０２は、実行時に、ファームウェアイメージ１００の開始点を示すコード空間シグネチャ１２０の位置が特定されるまで、不揮発性メモリユニット１０１内において、ファームウェアイメージ１００の複数のあり得る開始点の各々をチェックする。【選択図】　　　　　図１
2004013898.tif 000002
【特許請求の範囲】
【請求項１】
不揮発性メモリユニットにおいてファームウェアイメージの開始点の位置を特定する方法であって、
前記ファームウェアイメージ（１００）の前記開始点を示すコード空間シグネチャ（１２０）の位置が特定されるまで、前記不揮発性メモリユニット（１０１）内の複数のあり得る開始点の各々をチェックすること（１５１）
を含む方法。
【請求項２】
ホスト装置（１０８）の不揮発性メモリユニット（１００）におけるファームウェアイメージ（１００）の開始点の位置を特定するシステムであって、
前記ホスト装置（１０８）の前記不揮発性メモリユニット（１０１）と、
プロセッサ（１０７）によって実行されるために前記ホスト装置（１０８）に格納されるブートモジュール（１０２）と、
を具備し、
前記ブートモジュール（１０２）は、実行時に、前記ファームウェアイメージ（１００）の前記開始点を示すコード空間シグネチャ（１２０）の位置が特定されるまで、前記不揮発性メモリユニット（１０１）内において前記ファームウェアイメージ（１００）の複数のあり得る開始点の各々をチェックするように構成される
システム。
【請求項３】
不揮発性メモリユニット（１０１）において入来ファームウェアイメージ（１００ｂ）を格納することができる場所の位置を特定する方法であって、前記入来ファームウェアイメージ（１００ｂ）を受取ると、
前記不揮発性メモリユニット（１０１）の少なくとも１つのブロック（１０１ａ）を消去しようと試みること（１６４）と、
前記消去しようとする試みが成功した前記不揮発性メモリユニット（１０１）に前記入来ファームウェアイメージ（１００ｂ）を格納すること（１６６）と
を含む方法。
【請求項４】
前記不揮発性メモリユニット（１０１）に対しといあわせることであって、それにより該不揮発性メモリユニット（１０１）の前記少なくとも１つのブロック（１０１ａ）を消去しようと試みる（１６４）前に、該不揮発性メモリ（１０１）内のブートコードロケーションを特定する、問合せる（１６２）こと
をさらに含む請求項３記載の方法。
【請求項５】
前記不揮発性メモリユニット（１０１）の少なくとも１つのブロック（１０１ａ）を消去しようという前記試みることは、さらに、ホスト装置（１０８）のコネクタを通して前記入来ファームウェアイメージ（１００ｂ）を受取る前記少なくとも１つのブロック（１０１ａ）を消去しようと試みる前に、該不揮発性メモリユニット（１０１）の最初の部分をスキップすること
をさらに含む請求項３記載の方法。
【請求項６】
不揮発性メモリユニット（１０１）において、入来ファームウェアイメージ（１００ｂ）を格納することができる場所の位置を特定するシステムであって、
既存のファームウェアイメージ（１００ａ）を実行するホスト装置（１０８）のプロセッサ（１０７）を具備し、
該既存のファームウェアイメージ（１００ａ）は、前記入来ファームウェアイメージ（１００ｂ）の受取時に、不揮発性メモリユニット（１０１）の少なくとも１つのブロック（１０１ａ）の消去を試み（１６４）、該試みられた消去が成功する前記不揮発性メモリユニット（１０１）に前記入来ファームウェアイメージ（１００ｂ）を格納するように構成される
システム。
【請求項７】
入来ファームウェアイメージ（１００ｂ）を格納するメモリの位置を特定する方法であって、
ファームウェアイメージ（１００ａ）を、メモリ（１０１）に、該ファームウェアイメージのメモリ（１０１）内のロケーションに関する情報を含むヘッダとともに格納する
方法。
【請求項８】
メモリにおいてファームウェアイメージ（１００ａ）に関連するヘッダを探索すること（１５３）と、
該ヘッダの位置を特定することと、
前記入来ファームウェアイメージ（１００ｂ）を収容するために前記ヘッダに関連するメモリに十分な空間があるか否かを判断すること（１５４）と、
十分な空間がある場合、前記ヘッダに関連する前記入来ファームウェアイメージを格納すること（１５５）と
をさらに含む請求項７記載の方法。
【請求項９】
メモリにおける現ファームウェアイメージのロケーションに関する情報を取得すること（１５６）と、
前記位置が特定されたヘッダのロケーションと現ファームウェアイメージの前記ロケーションとの間に、前記入来ファームウェアイメージ（１００ｂ）を収容するために十分な空間があるか否かを判断すること（１５７）と、
十分な空間がある場合、前記位置が特定されたヘッダの前記ロケーションと現ファームウェアイメージの前記ロケーションとの間に前記入来ファームウェアイメージ（１００ｂ）を格納すること（１５９）と
を
さらに含む請求項８記載の方法。
【請求項１０】
前記現ファームウェアイメージの後に前記入来ファームウェアイメージを収容するために十分な空間があるか否かを判断すること（１６２）と、
十分な空間がある場合、前記現ファームウェアイメージの後に前記入来ファームウェアイメージを格納すること（１６３）と
をさらに含む請求項９記載の方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、ファームウェアの技術分野に関する。より詳細には、本発明は、不揮発性メモリにおいてファームウェアイメージの位置を特定する方法およびシステムに関する。
【０００２】
【従来の技術】
ファームウェアは、電子機器に格納されてその機器の動作を制御するコンピュータコードまたはソフトウェアである。
たとえば無線電話、セットトップボックス、デジタル音楽プレイヤー等の多くの電子機器が、ファームウェアを使用して動作する。
ファームウェアが格納され実行される機器は、しばしばホストまたはホスト装置と呼ばれる。
【０００３】
ファームウェアは、通常、ホスト装置の不揮発性メモリユニット、たとえばフラッシュメモリユニットに格納される。
不揮発性メモリユニットは、そのメモリユニットへの電力が切断された場合にもデータを保持する。
したがって、ファームウェアは、ホスト装置が停止状態である間保持され、ホストが起動された時に使用可能である。
【０００４】
ホスト装置が起動されると、ファームウェアは、通常、揮発性メモリ、たとえばランダムアクセスメモリ（ＲＡＭ）にロードされ、ホスト装置のプロセッサによって実行される。
プロセッサによってファームウェアが実行されることにより、装置は動作し、装置はホスト装置に対して意図された機能（複数可）を提供する。
ファームウェアは、装置の機能を提供するだけでなく、ユーザがホスト装置の機能を制御することができるようにするユーザインタフェースも含んでよい。
【０００５】
また、ホスト装置は、通常、不揮発性メモリにブートモジュールまたはブートアルゴリズムを格納する。
このブートモジュールは、ホスト装置を始動させるために必須である。
ホスト装置が始動すると、ブートモジュールはプロセッサに対し、ホストのファームウェアがロードおよび実行されホスト装置の制御を引継ぐまでホスト装置を作動させる、初期命令を提供する。
【０００６】
ブートモジュールの重要な機能は、不揮発性メモリにおいてファームウェアの位置を特定することである。
そして、ファームウェアは、プロセッサによって実行されるために不揮発性メモリから検索されまたは読出される。
このように、ブートモジュールは、不揮発性メモリユニットにおいてファームウェアイメージの位置を特定する何らかの手段を有していなければならない。
【０００７】
従来、この位置特定機能では、不揮発性メモリユニットが特定のアーキテクチャを有すると期待されるようにブートモジュールを構成していた。
しかしながら、不揮発性メモリユニットが異なるアーキテクチャを有するユニットに置換えられる場合、従来のブートモジュールは、起動時に使用するファームウェアイメージの位置を特定することができなかった。
【０００８】
ファームウェアは、最初に、稼動状態になる前のホスト装置にロードされる。その後、しばしば、ホスト装置においてファームウェアを変更またはアップグレードすることが必要または望ましくなる。
たとえば、新たなファームウェアバージョンは、初期のバージョンより頑強に動作する可能性がある。
また、新たなファームウェアバージョンは、追加の機能を提供する、すなわちホスト装置の機能を拡張する可能性がある。
【０００９】
ファームウェアが最初にまたはアップグレードの一部としてホスト装置にダウンロードされる場合、ファームウェアは、不揮発性メモリのいずれかの位置に格納されなければならない。
入来ファームウェアに対して選択される位置が、利用可能であり適当であることが重要である。
特に、入来ファームウェアが、同様に不揮発性メモリユニットに格納されるブートモジュールの上に書込まれないことが極めて重要である。
【００１０】
【発明が解決しようとする課題】
本発明の目的は、不揮発性メモリユニットにおいて、ファームウェアイメージの位置を特定する方法およびシステムを提供することである。
【００１１】
【課題を解決するための手段】
一実施形態では、本発明は、不揮発性メモリユニットにおいてファームウェアイメージの開始点の位置を特定する方法であって、ファームウェアイメージの開始点を示すコード空間シグネチャの位置が特定されるまで、不揮発性メモリユニット内の複数のあり得る開始点の各々をチェックすることを含む方法であってよい。
【００１２】
別の実施形態では、本発明は、ホスト装置の不揮発性メモリユニットにおけるファームウェアイメージの開始点の位置を特定するシステムであって、ホスト装置の不揮発性メモリユニットと、プロセッサによって実行されるためにホスト装置に格納されるブートモジュールとを備え、　ブートモジュールが、実行時に、ファームウェアイメージの開始点を示すコード空間シグネチャの位置が特定されるまで、不揮発性メモリユニット内のファームウェアイメージの複数のあり得る開始点の各々をチェックするように構成されるシステムであってよい。
【００１３】
別の実施形態では、本発明は、不揮発性メモリユニットにおいて入来ファームウェアイメージを格納することができる場所の位置を特定する方法であって、入来ファームウェアイメージを受取ると、不揮発性メモリユニットの少なくとも１つのブロックを消去しようと試みることと、試みた消去が成功した不揮発性メモリユニットに入来ファームウェアイメージを格納することと、を含む方法であってよい。
【００１４】
別の実施形態では、本発明は、ホスト装置の不揮発性メモリユニットにおいて、入来ファームウェアイメージを格納することができる場所の位置を特定するシステムであって、既存のファームウェアイメージを実行するホスト装置のプロセッサと、ホスト装置の入来ファームウェアイメージを受取るチャネルと、ホスト装置の不揮発性メモリユニットとを備え、既存のファームウェアイメージが、入来ファームウェアイメージの受取時に、不揮発性メモリユニットの少なくとも１つのブロックの消去を試み、試みられた消去が成功した不揮発性メモリユニットに入来ファームウェアイメージを格納するように構成されるシステムであってよい。
【００１５】
添付図面は、本発明の実施形態を例示し、明細書の一部である。
以下の説明とともに、図面は、本発明の原理を論証し説明する。
例示する実施形態は、本発明の実施例であり発明の適用範囲を限定するものではない。
【００１６】
図面を通して、同じ参照符号は、同様であるが必ずしも同じではない要素を示す。
【００１７】
【発明の実施の形態】
本発明は、メモリユニット内でファームウェアイメージの開始点の位置を特定する方法を提供する。
本発明は、さらに、ファームウェアイメージをダウンロード及び格納する時に回避されるべきブートコードをメモリユニットのいずれのブロックが含むかを識別する方法を提供する。
本発明の技法のうちのいくつかは、メモリユニットに関する情報を、ファームウェアダウンロードを処理するソフトウェアに提供しまたはそこから獲得する方法を含む。
たとえば、実行中ファームウェアイメージは、概して、フラッシュメモリチップに対し問合せを行うことにより、そのメモリチップに特有のメモリセクタサイズと消去アルゴリズムとを確定する。
フラッシュメモリチップでは、多くの異なる消去アルゴリズムが使用される。比較として、ブートコードは、フラッシュメモリユニットのみを読出せばよく、その読出しプロセスは常に同じ方法で実行される。
一方、ファームウェアダウンロードを管理するソフトウェアは、メモリユニット内においてデータの消去と書込みとの両方を処理しなければならない。
【００１８】
図１は、所望の機能を提供するためにファームウェアの部分を格納し実行する例示的なホスト装置のブロック図である。
図１に示すように、ホスト装置（１０８）は、不揮発性メモリユニット（１０１）、たとえばフラッシュメモリユニットを含む。
この不揮発性メモリユニット（１０１）は、単一の不揮発性メモリデバイスであってよく、あるいは複数の不揮発性メモリデバイスであってもよい。
不揮発性メモリユニット（１０１）は、１つまたは複数のファームウェアイメージ（１００）とブートモジュール（１０２）とを含む。
【００１９】
ホスト装置（１０８）はまた、プロセッサ（１０７）と好ましくはランダムアクセスメモリ（ＲＡＭ）（１０４）とを含む。
プロセッサ（１０７）は、通常、ファームウェア（１００）をＲＡＭ（１０４）にロードし、その後ファームウェア（１００）を実行する。
データバス（１０３）は、プロセッサ（１０７）とＲＡＭ（１０４）とフラッシュメモリユニット（１０１）とを相互接続し、それによってデータをホスト装置（１０８）の各種コンポーネント間で送信することができる。
【００２０】
コネクタまたはトランシーバ（１０５）はチャネルであり、それを通して、ファームウェアイメージ等のデータをホスト装置（１０８）にダウンロードすることができる。
また、コネクタ／トランシーバ（１０５）は、バス（１０３）に接続し、したがって、バス（１０３）に接続されるホスト装置（１０８）の各種コンポーネントにデータを提供することができる。
【００２１】
コネクタ／トランシーバ（１０５）がコネクタである場合、コネクタを使用して、ホスト装置（１０８）を、ネットワークか、またはホスト装置（１０８）にデータを提供することができるコンピュータ等の別の装置に接続することができる。
たとえば、コネクタ（１０５）を、インタネット、ローカルエリアネットワーク（Ｌｏｃａｌ　Ａｒｅａ　Ｎｅｔｗｏｒｋ（ＬＡＮ））または広域ネットワーク（Ｗｉｄｅ　Ａｒｅａ　Ｎｅｔｗｏｒｋ（ＷＡＮ））への接続部とすることができる。
代替的に、コネクタを使用して、ホスト装置（１０８）を、コンピュータ、サーバ、ディスクドライバ、またはファームウェアイメージ等のデータをホスト装置（１０８）に提供する他の装置に接続することができる。
コネクタ（１０５）は、たとえば、シリアル接続部、ユニバーサルシリアルバス（Ｕｎｉｖｅｒｓａｌ　Ｓｅｒｉａｌ　Ｂｕｓ（ＵＳＢ））接続部、電気電子学会（Ｉｎｓｔｉｔｕｔｅ　ｏｆ　Ｅｌｅｃｔｒｉｃａｌ　ａｎｄ　Ｅｌｅｃｔｒｏｎｉｃｓ　Ｅｎｇｉｎｅｅｒｓ（ＩＥＥＥ））１３９４接続部等であってよい。
【００２２】
コネクタ／トランシーバ（１０５）がトランシーバである場合、トランシーバを使用して、たとえばホスト装置（１０８）においてデータを無線で受信することができる。
トランシーバ（１０５）は、光、赤外線、無線周波数または他のタイプのトランシーバであってよい。
本発明の原理内で、データ、すなわちファームウェアイメージをホスト装置（１０８）にダウンロードするいかなる手段も使用することができる。
【００２３】
ホスト装置（１０８）に最初に電源投入されると、プロセッサ（１０７）は、自動的にブートコードモジュール（１０２）をフラッシュメモリ（１０１）からＲＡＭ（１０４）にロードする。
プロセッサ（１０７）は、ＲＡＭ（１０４）からブートコード（１０２）を実行することができる。
ブートコード（１０２）は、ホスト装置（１０８）に対し、ファームウェアをロードし実行することを含む動作を開始させることができるようにする初期命令を提供する。
したがって、ファームウェアのフラッシュメモリ（１０１）からＲＡＭ（１０４）へのロードを監視するのは、ブートコード（１０２）である。
【００２４】
ブートコード（１０２）は、不揮発性メモリ（１０１）においてファームウェアイメージ（１００）の位置を特定する。
ファームウェア（１００）は、不揮発性メモリユニット（１０１）のどこかに開始点を有する。
この開始点の位置が特定されると、ファームウェア（１００）を、実行するために不揮発性メモリ（１０１）から読出しＲＡＭ（１０４）に格納することができる。
しかしながら、メモリ（１０１）においてファームウェアイメージ（１００）の位置を単に特定することは、困難である可能性がある。
【００２５】
ホスト装置においてそのホストに対してダウンロードされたファームウェアを格納するために頻繁に使用されるフラッシュメモリデバイスは、メモリの製造業者とメモリのタイプとの両方によって、異なるメモリ編成フォーマットを有する可能性がある。
また、フラッシュメモリチップは、頻繁に陳腐化して、先のバージョンと同じメモリレイアウトを有していない可能性のある新しいバージョンに置換される。
したがって、先述したように、ブートコードは、ファームウェアイメージが、現在インストールされたフラッシュメモリユニット内のどこで開始するかを必ずしも知らない可能性がある。
【００２６】
図２に示すように、フラッシュメモリユニット（１０１）は、一般に、メモリブロック（１０１ａ）に分割される。
かかる各ブロック（１０１ａ）は、ブロックとして消去されなければならない、すなわち、メモリブロックの一部のみを消去することができない。
ファームウェアイメージ（１００）は、通常、ブロック（１０１ａ）の始まりで開始する。
したがって、メモリユニット（１０１）内において、ファームウェアイメージ（１００）が開始することができる場所、すなわち各ブロック（１０１ａ）の始まりの数には限りがある。
たとえば、フラッシュメモリブロックのサイズは、通常２の倍数であり通常は少なくとも４０９６バイトであって、そのためファームウェアイメージは通常４０９６バイト境界で開始する。
あり得る開始ロケーションを、ダウンロードプロセスが１メガバイトより大きいメモリユニットに対し１２８Ｋバイト境界にのみコードをロードするように要求すること等により、定義によってさらに低減することが可能である。
【００２７】
本発明の原理の下では、メモリ（１０１）の他のどこかでランダムに発生する可能性の低いコード空間シグネチャ（１２０）が画定される。
このコード空間シグネチャ（１２０）は、図２に示すように、ファームウェアイメージ（１００）の始まりに配置される。
【００２８】
当業者には認められるように、コード空間シグネチャを画定することができる方法には略無限の数がある。
メモリユニット（１０１）においてランダムに発生する可能性が低くファームウェアイメージ（１００）の始まりを特定するいかなるコード空間シグネチャ（１２０）も、本発明の範囲内にある。
例として、文字列「ＣＯＤＥ　ＳＴＡＲＴ」を、その文字列に対するチェックサムが続くコード空間シグネチャ（１２０）として使用することができる。
【００２９】
上述したように、ブートモジュール（１０２）は、ホスト装置が最初に起動された時にプロセッサ（１０７）によって実行される。
後に詳細に説明するように、本発明によるブートモジュール（１０２）は、メモリユニット（１０１）内のあり得る開始点に対し、メモリユニット（１０１）内のファームウェアイメージの始まりを示すコード空間シグネチャ（１２０）を探索する。
コード空間シグネチャ（１２０）の位置が特定されると、ファームウェア（１００）を、実行するために不揮発性メモリユニット（１０１）から読出すことができる。
このように、ブートモジュール（１０２）は、特定の不揮発性メモリアーキテクチャによって決まらない。
むしろ、ホスト装置の電源投入時にブートモジュール（１０２）がファームウェアイメージ（１００）の位置を特定することができないことに起因する問題をもたらすことなく、不揮発性メモリユニット（１０１）を必要に応じて置換またはアップグレードすることができる。
【００３０】
本発明の原理による不揮発性メモリにおけるファームウェアイメージの開始点の位置を特定する方法を、たとえば図３に示す。
図３に示すように、まずブートコードをロードし実行する（ステップ１５０）。
ブートコードは、コード空間シグネチャの位置が特定されるまで、あり得るコード開始点、たとえばメモリブロックの始まりのすべてに対し、コード空間シグネチャを探索する（ステップ１５１）。
したがって、たとえば、ブートコードは、フラッシュメモリユニットの最初の３２Ｋにおいて４Ｋ（４０９６バイト）毎に、１２８Ｋまで３２Ｋ毎に、４，０００Ｋまで１２８Ｋ毎に、そして５１２Ｋの倍数単位でチェックする。
コード空間シグネチャの位置が特定されると（判断１５２）、対応するファームウェアイメージの開始点の位置もまた特定される。
そして、ファームウェアをロードし（ステップ１５３）実行することができる（１５４）。
【００３１】
大抵のホスト装置の起動手続き中、ファームウェアイメージの開始を探索するために費やす時間はわずかである。
この方式を使用してファームウェアイメージの位置を特定することにより、不揮発性メモリを異なるアーキテクチャを有する新たな不揮発性メモリデバイスに変更することによって、ブートモジュールの使用は影響を受けない。
このため、ホスト装置において不揮発性メモリをアップグレードすることがより容易になる。
【００３２】
図４は、本発明の原理による、ホスト装置にダウンロードされている入来ファームウェアイメージを格納する不揮発性メモリの位置を識別する方法を示すフローチャートである。
ファームウェアイメージを格納する場合、重要な考慮点は、同様に不揮発性メモリに格納されているブートコードモジュールに上書きしない、ということである。
ブートコードモジュールが上書きされると、ホスト装置は動作不能となる。
【００３３】
フラッシュメモリユニットによっては、ブートコードモジュールが格納される領域をロックすることができるものがある。
言換えれば、ブートコードモジュールが格納されるメモリブロック（複数可）を消去することができない。
他のフラッシュメモリチップには、共通フラッシュインタフェース（Ｃｏｍｍｏｎ　ｆｌａｓｈ　Ｉｎｔｅｒｆａｃｅ（ＣＦＩ））仕様に準拠するものもある。
この仕様は、チップに対しそのタイプおよび他の基本情報を問合せる方法を示す。
したがって、チップは、適当な問合せに応答して、ブートコードのロケーションを含むそのアーキテクチャを報告することができる。
ＣＦＩコマンドに応答しないチップの場合、ファームウェアは、いずれのタイプのチップがロードされているかを見出しそのチップに関する基本情報を取得するためにすべての周知のフラッシュチップ問合せコマンドを試行してよい。
ブートコードモジュールの問合せまたはロッキングをサポートしないフラッシュメモリチップでは、ブートコードを、メモリ空間の最初の８Ｋにあるように画定してよい。
【００３４】
図４に示すように、入来ファームウェアイメージを、不揮発性（たとえばフラッシュ）メモリにおける長期記憶に先立って揮発性メモリに一時的に書きこんでよい（ステップ１６０）。
不揮発性メモリが、ＣＦＩ仕様に準拠するフラッシュメモリユニットである場合（判断１６１）、新たな入来ファームウェアイメージの受取りを制御している実行中ファームウェアにより、問合せをフラッシュメモリユニットに送出すことができる（ステップ１６２）。
フラッシュメモリユニットは、ＣＦＩ仕様にしたがい、ブートコードイメージが位置する場所とファームウェアイメージの開始点になりそうな所とを定義する、フラッシュメモリユニットのアーキテクチャに関する情報によって応答する。
【００３５】
そして、この応答にしたがって、揮発性メモリからフラッシュメモリに入来ファームウェアを書込むことができる（ステップ１６３）。
言換えれば、入来ファームウェアを、フラッシュメモリユニットのブートコードモジュールと競合しないロケーションに書込むことができる。
【００３６】
目的が先のファームウェアイメージに上書きすることである場合、上述したアルゴリズムを使用して、入来ファームウェアを格納すべき場所を特定することができる。
言換えれば、コード空間シグネチャの探索を、不揮発性メモリにおいて既存のファームウェアイメージが開始する場所を特定するように行うことができる。
そして、このロケーションを、新たな入来ファームウェアイメージを保存する開始点として使用する。
そして、入来ファームウェアイメージは、先のファームウェアイメージに上書きする。
この方法を、複数のファームウェアイメージを含むフラッシュユニットに特定のファームウェアイメージを上書きするように、容易に拡張することができる。
【００３７】
不揮発性メモリユニットは、ＣＦＩ仕様に準拠しないフラッシュメモリユニットである場合、ブートコードのロックされた領域、すなわち消去することができないブートコードを含む領域を有する可能性がある。
【００３８】
したがって、ダウンロードを制御するファームウェアは、逐次、入来ファームウェアイメージを格納することができるメモリのブロックを消去するよう試みてよい（ステップ１６４）。
ブロックがロックされている場合、消去は失敗する（判断１６５）。
消去が成功した場合、消去されたブロックは、ブートコードを含むロックされたブロックではなかったことになる（判断１６５）。
そして、入来ファームウェアイメージを消去されたブロックに書込むことができる（ステップ１６６）。
フラッシュユニットによってはロッキングをサポートしないため、メモリの最初の８Ｋ内にブートコードを格納するデバイスが損傷しないように、最初の８Ｋの後で消去を試みることが好ましい。
【００３９】
図５は、図４に示す方法を使用して入来ファームウェアイメージを格納することができるメモリのロケーションを特定する、ホスト装置において使用するシステムを示す。
図５に示すように、ホスト装置は、新たな入来ファームウェアイメージ（１００ｂ）を受取る時、通常動作中である。
したがって、既存のファームウェアイメージ（１００ａ）は、ホスト装置のプロセッサ（１０７）によって実行されている。
【００４０】
本発明の原理の下では、既存のファームウェアイメージ（１００ａ）は、入来ファームウェアイメージ（１００ｂ）のダウンロードおよび格納を管理するように構成される。
したがって、実行中ファームウェア（１００ａ）は、不揮発性メモリユニット（１０１）において、ブートモジュール（１０２）を危険に晒すことなく入来ファームウェア（１００ｂ）を格納することができる場所を確定しなければならない。
【００４１】
本発明のシステムの一実施形態は、ブートモジュール（１０２）を含むメモリブロック（複数可）（１０１ｂ）がロックされるという想定の下に動作し、それは、実行中ファームウェア（１００ａ）がロックされたブロック（１０１ｂ）を消去することができないことを意味する。
したがって、入来ファームウェアイメージ（１００ｂ）を受取ると、実行中ファームウェア（１００ａ）は、不揮発性メモリユニット（１０１）のブロック（１０１ａ）に消去コマンド（１２１）を送信する。
その際に、実行中ファームウェア（１００ａ）は、不揮発性メモリ（１０１）から独自のイメージを消去してよい。
【００４２】
ブロックがロックされている場合（たとえば、１０１ｂ）、消去コマンドは失敗する。
これは、そのブロック（１０１ｂ）がブートモジュール（１０２）の一部またはすべてを含むことを示す。
消去コマンドが成功した場合、ブロック（たとえば、１０１ａ）は消去され、ブートモジュール（１０２）を含まなかったことになる。
そして、実行中ファームウェア（１００ａ）は、消去コマンド（１２１）が成功した１つまたは複数のブロックにおける入来ファームウェアイメージ（１００ｂ）の格納を安全に指示することができる。
このように、入来ファームウェア（１００ｂ）は、不揮発性メモリ（１０１）に適当に格納される。
【００４３】
入来ファームウェアイメージ（１００ｂ）は、不揮発性メモリ（１０１）に格納された後、不揮発性メモリ（１０１）に存在する唯一のファームウェアイメージであってよい。
言換えれば、実行中ファームウェア（１００ａ）のイメージを、不揮発性メモリユニット（１０１）の各種メモリブロックに発行された消去コマンド（１２１）によって消去してよい。
【００４４】
ホスト装置が再始動される時、ブートモジュール（１０２）はロードし実行する。
そして、ブートモジュール（１０２）は、不揮発性メモリからファームウェアイメージをロードし実行しようとする。
ブートモジュール（１０２）は、上述した方法を使用して、不揮発性メモリにおける新たに格納された入来ファームウェア（１００ｂ）の開始点を見つけてよい。
そして、入来ファームウェア（１００ｂ）はロードおよび実行され、ホスト装置の実行中ファームウェアとなる。
【００４５】
上述した「消去しようとする」方法に対する代替態様は、すべてのファームウェアイメージが、フラッシュメモリ空間要件に関する情報を提供するヘッダと現格納ロケーションのフィールドとを含む、ということを必要とするというものである。
ブートコードは、ファームウェアイメージを選択し、そのファームウェアイメージをメモリにコピーする。
また、ブートコードは、実行中ファームウェアがフラッシュメモリにおいてファームウェアイメージのコピーが存在する場所を知るように、現格納ロケーションのヘッダフィールドを充填する。
特に、ヘッダは、好ましくはイメージが格納される場所を示すフィールド、たとえば「Ｍｙ　Ｌｏｃａｔｉｏｎ」と、イメージが終了する場所を示すフィールド、たとえば「Ｍｙ　Ｅｎｄ」とを有する。
【００４６】
図６は、本発明の方法のこの実施形態を示す。
図６に示すように、本方法は、新たなファームウェアイメージがダウンロードされる用意ができている時に開始する（１５１）。
上述したように、ダウンロードを処理する責務を有する実行中ファームウェアイメージは、メモリにおける独自のイメージのＭｙ　ＬｏｃａｔｉｏｎおよびＭｙ　Ｅｎｄ情報を有する（１５２）。
【００４７】
そして、実行中ファームウェアは、メモリにおいてヘッダを探索する（１５３）。
探索は、好ましくは、８Ｋバイトの後の最初のセクタで開始して、ファームウェアヘッダのセクタ毎の探索である。
ブートコードが最初の８Ｋバイトに格納されている可能性があるということと、８Ｋの後の最初のセクタはファームウェア格納に利用可能であるということとが推定される。
【００４８】
ヘッダが見つかると、実行中ファームウェアは、ヘッダの前に入来ファームウェアイメージを収容するために十分な未使用空間があるか否かを判断する（１５４）。
十分な未使用空間がある場合、入来ファームウェアイメージダウンロードを、ヘッダの前に格納することができる（１５５）。
ヘッダの前に十分な自由空間がない場合、実行中ファームウェアは、「Ｍｙ　Ｌｏｃａｔｉｏｎ」によって示されているような独自のイメージのロケーションを読出しているか否かを判断する（１５６）。
【００４９】
これが実行中ファームウェア独自のイメージのロケーションでない場合、実行中ファームウェアは、このロケーションと「Ｍｙ　Ｌｏｃａｔｉｏｎ」との間に入来ファームウェアイメージを収容するために十分な未使用空間があるか否かを判断する（１５７）。
十分な未使用空間がある場合、入来ファームウェアイメージをこのロケーションと「Ｍｙ　Ｌｏｃａｔｉｏｎ」との間に格納することができる（１５９）。
【００５０】
次いで、実行中ファームウェアは、独自のイメージの終り、たとえば「Ｍｙ　Ｅｎｄ」の位置を特定することができる（１６０）。
そして、「Ｍｙ　Ｅｎｄ」とメモリの終りとの間で探索を行うことにより、入来ファームウェアイメージを収容するために十分な空間があるか否かを判断する（１６２）。
十分な空間がある場合、入来ファームウェアイメージを「Ｍｙ　Ｅｎｄ」に続いて格納することができる（１６３）。
十分な空間がない場合、実行中ファームウェアは、入来ファームウェアイメージを収容するためにメモリ（１６４）に独自のイメージを上書きしなければならない可能性がある。
【００５１】
ブートコードをフラッシュチップの略いかなるタイプの使用をもサポートするように１回書込むことができ、いくつかの異なるタイプのチップを理解するようにメインファームウェアを書込むことができるため、本発明は、その多くの可能な実施形態において重要である。
フラッシュデバイス等、メモリデバイスタイプを、たとえばコスト低減のためかまたは先のチップが陳腐になったために変更しなければならない場合、本発明により、ブートコードと実行中ファームウェアとが、新たなチップに順応し、適当に新たな入来ファームウェアを格納することが可能になる。
【００５２】
【発明の効果】
以上説明したように、本発明にかかる方法およびシステムによれば、不揮発性メモリユニットにおいて、ファームウェアイメージの位置を特定することができる。
【図面の簡単な説明】
【図１】本発明の原理による、フラッシュメモリデバイスにファームウェアおよびブートモジュールイメージを有するホスト装置の例示的な実施形態のブロック図である。
【図２】不揮発性メモリにおいてファームウェアイメージの開始点の位置を特定する、本発明の原理によるシステムの実施形態を示すブロック図である。
【図３】不揮発性メモリに格納されるファームウェアイメージの開始点の位置を特定する、本発明の原理による方法の実施形態を示すフローチャートである。
【図４】入来ファームウェアイメージを格納することができるメモリの位置を特定する、本発明の原理による方法の実施形態を示すフローチャートである。
【図５】入来ファームウェアイメージを格納することができるメモリの位置を特定する、本発明の原理によるシステムの実施形態を示すブロック図である。
【図６】本発明の原理による、入来ファームウェアイメージを格納するためのメモリの場所の位置を特定する方法の別の実施形態を示すフローチャートである。
【符号の説明】
１００・・・ファームウェアイメージ、
１０１・・・フラッシュメモリユニット、
１０２・・・ブートモジュール、
１０４・・・ＲＡＭ、
１０５・・・コネクタ／トランシーバ、
１０７・・・プロセッサ、
１０８・・・ホスト装置、
【図１】
2004013898.tif 000003
【図２】
2004013898.tif 000004
【図３】
2004013898.tif 000005
【図４】
2004013898.tif 000006
【図５】
2004013898.tif 000007
【図６】
2004013898.tif 000008