(57)【要約】【課題】  ファームウェア書換え後のブートに失敗した場合、以前のファームウェアバージョンからのブートを容易にする。【解決手段】  フラッシュメモリ内の限られた領域に２つのファームウェアを格納する為、フラッシュメモリを書込み可能な単位で分割し、書換え時は変更のあるモジュール単位で書き換える。変更のあるモジュールの差分データを作り、書き換え領域の縮小を行う。フラッシュメモリ内のモジュールの領域と空き領域を管理し、以前のレビジョンモジュールを上書き消去せず残し、書換え後のブートに失敗した場合、以前のバージョンのファームウェアからの復旧を可能とする。【選択図】  図１
2005321843.tif 000002
【特許請求の範囲】
【請求項１】
ファームウェアを格納するフラッシュメモリ内を複数の領域に分割し、ファームウェアを構成するモジュールが格納されている領域と、空き領域とを書込みの優先度を設定して管理し、バージョンアップ時には以前のファームウェアバージョンのモジュールを上書き消去せず、復旧が可能なように優先度を参照して書込む領域を自動判別することを特徴としたファームウェアの書換え方法。
【請求項２】
ファームウェアを構成する各モジュールを、モジュール処理開始エントリポイントへのジャンプにより処理実行される独立したモジュールで構成し、書換え時には変更のあるモジュールのみを書込み、ファームウェアバージョンを構成するモジュールレビジョンを管理し、バージョンに応じて動作させるモジュール構成を切り換えることで、限られたフラッシュメモリに２つのバージョンのファームウェアを格納することを特徴とした請求項１のファームウェアの書換え方法。
【請求項３】
変更対象となるモジュールのうち、モジュールをＲＡＭ上に展開して動作するモジュールに関しては、新しいファームウェアバージョンのモジュールと、以前のファームウェアバージョンのモジュールとの差分データを作成し、モジュールを書込む為に必要なブロック数より差分データを書込む為に必要なブロック数の方が少ない場合は差分データを書込むことを特徴とした請求項１又は、請求項２のファームウェアの書換え方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はファームウェアの書換え方法に関し、特に書換え可能なフラッシュメモリを備えるシステムのファームウェアの書換えを安全に行う方法に関する。
【背景技術】
【０００２】
従来、ファームウェアを格納するフラッシュメモリを複数面持たないシステムのファームウェアの書換えは、ファームウェアイメージ全体の書換え、もしくは特開２００２−３４２１００号公報にあるような変更部分のみの書換えにより、フラッシュメモリ内のファームウェアイメージを常に新しいバージョンのファームウェアに上書き更新していた。
【０００３】
【特許文献１】特開２００２−３４２１００号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
従来の上書き方法では書換えを行ったバージョンのファームウェアのブートに失敗した場合、以前のバージョンのファームウェアに戻す方法は、再度ファームウェアの書換えを行う他なく、書換え作業に要する時間やコストがかかるという課題がある。
【課題を解決するための手段】
【０００５】
前記課題を解決するため、本発明のファームウェア書換え方法は、ファームウェアを格納するフラッシュメモリ内を複数の領域に分割し、フラッシュメモリ内のファームウェアを構成するモジュールの領域と空き領域の書換え優先度を管理し、以前のバージョンのモジュールを上書きせず書込みを行う領域を決定し、書込みを行う単位をファームウェア全体でなく、ファームウェアを構成するモジュール単位とし、尚且つ変更のあるモジュールのみとすることで、書換えに必要なフラッシュメモリの領域を縮小し、以前のファームウェアバージョンを残し、復旧を可能にするものである。
【発明の効果】
【０００６】
本発明によりファームウェアの書換え後のブートに失敗した場合、以前のバージョンのファームウェアからブートを行うことが可能な為、以前のファームウェアバージョンに戻す作業時間が不要となり、さらに通常のファームウェアの書換え作業時間の短縮が可能である。
【発明を実施するための最良の形態】
【０００７】
図１、図２、図３を用いてフラッシュメモリに２つのファームウェアを格納する為の管理方法を述べる。図１は本発明においてファームウェアを格納するフラッシュメモリ１００の図であり、１つのファームウェアバージョンしか存在しない場合は、ファームウェアイメージそのものである。ファームウェアイメージは書込みをするファームウェア全体のデータであり、初期書込みの際に妥当なモジュール配置となるエントリブロック１０１内情報を含むものとする。例としてフラッシュメモリ１００のファームウェアバージョン０００３を構成するモジュールは、フラッシュメモリ１００で実行される最初のコードのモジュール1（レビジョン１）、ＲＡＭ上で展開実行されるモジュール２(レビジョン２)、モジュール３(レビジョン１)とする。
【０００８】
エントリブロック１０１には通常、パワーオン直後最初に実行するコードのアドレスを示すファームウェアエントリポイント１０６が存在するが、２つのバージョンのモジュール１が同一レビジョンでないことを考慮し、バージョンに対応したモジュール1のエントリポイントを判断する為、ファームウェアエントリポイント１０６にはエントリポイント判定処理１１０のアドレスを登録する。
【０００９】
エントリポイント判定処理１１０は、図２のフラッシュメモリ１００の領域管理テーブル１０７と図３のバージョン構成情報１０８を参照し、対象となるバージョンのモジュール１のジャンプ先アドレスをサーチし、ジャンプを行う。
【００１０】
動作するファームウェアバージョンは通常、書換えを行ったファームウェアのバージョンであり、カレントファームウェアバージョン１０９に情報を格納する。
【００１１】
図２はフラッシュメモリ１００のモジュールのレビジョン、配置位置、サイズ、書換え優先度を管理している領域管理テーブル１０７の例である。書換え優先度は書換え時に以前のモジュールを上書き消去しないように、書換え可能な領域を管理するものである。書換え優先度は空き領域を“高”とし、優先的に書込みが行われる。カレントファームウェアバージョン１０９を構成するモジュールの領域は“書換え禁止”とし、書込みを認めない。以前のバージョンを構成するモジュールの領域は書換え優先度“低”とし、空き領域のサイズでは足りない場合に書換えを認める。モジュールのレビジョン、配置位置、サイズは、図３のバージョン構成情報１０８のカレントファームウェアバージョンを構成するモジュールのレビジョン情報と共に参照する。カレントファームウェアバージョンのファームウェアをブートする為、必要なモジュール構成をバージョン構成情報１０８から取得し、該当するレビジョンのモジュールを領域管理テーブル１０７の配置位置から実行のエントリポイント取得や、ＲＡＭ上へ展開する為に読み出しを行う。
【００１２】
ＲＡＭ上に展開して実行するモジュールが差分データである場合、先にベースとしたレビジョンのモジュールをＲＡＭ上に展開し、差分データに置換し命令を実行する。
【００１３】
図４と図５のフローを用いてファームウェア書換え時に従来のバージョンのファームウェアを消去せずに２つのファームウェアを格納する方法について説明する。
ステップＳ２００：新たに書込まれるファームウェアイメージの各モジュールのレビジョンを比較する。同一であればそのモジュールの書込みは不要である。
書込みが不要な場合、次のモジュールの比較を行う。
ステップＳ２０１：書込むモジュールがＲＡＭ上に展開して実行するモジュールか判断する。
【００１４】
ＲＡＭ上で実行可能なモジュールであれば、ステップＳ２０２で以前のレビジョンのモジュールとの差分データを抽出する。差分データにはベースとなったモジュールのレビジョンと、差分位置、差分の長さ、データ情報を抽出しておく。ＲＡＭ上で実行可能でないモジュールである場合はモジュールデータそのものを書込み対象のデータとする。
ステップＳ２０３：抽出した差分データのブロックサイズがモジュールでデータを書込む為に必要なブロックサイズより小さい場合、ステップＳ２０４にて差分データを書込み対象データとする。サイズが同一の場合は差分にするメリットが無い為、ステップＳ２０５にてモジュールデータを書込み対象データとする。
ステップＳ２０６：領域管理テーブル１０７の書換え優先度を参照し、書換え優先度“高”の空き領域に書込み対象データが格納可能か判定する。
ステップＳ２０７：空き領域に格納できない場合、書換え優先度“低”である二世代前のレビジョンのモジュール領域に格納可能か判定する。格納不可能な場合は２つのファームウェアイメージを格納不可能とし、ステップＳ２０８にてフラッシュメモリ１００へ新たなバージョンのファームウェアイメージ全体を書込み、処理を終了する。
ステップＳ２０９：格納可能な領域を発見した場合、書込み対象データを書込む。
ステップＳ２１０：全てのモジュールについてステップＳ２００からの処理を行う。
ステップＳ２１１：全てのモジュールの書込みが終了した時点で領域管理テーブル１０７とバージョン構成情報１０８、カレントファームウェアバージョン１０９を更新する。
【００１５】
ファームウェアのブート状態を管理しておき、正常にブートしなかった場合はバージョン構成情報１０８から以前のファームウェアバージョンを読み出し、カレントファームウェアバージョン１０９を以前のバージョンに書換え、領域管理テーブルの書換え優先度を更新することによって以前のバージョンのファームウェアからのブートが可能となる。
【図面の簡単な説明】
【００１６】
【図１】本発明を実施するための最良の形態におけるフラッシュメモリのメモリ空間とファームウェアイメージのモジュール配置を示す図。
【図２】本発明を実施するための最良の形態における２つのファームウェアバージョンを管理する為のフラッシュメモリ内の領域管理テーブル。
【図３】本発明を実施するための最良の形態における各バージョンのファームウェアを構成するモジュールのレビジョン情報。
【図４】本発明を実施するための最良の形態におけるファームウェア書換え時のフローチャート。
【図５】本発明を実施するための最良の形態におけるファームウェア書換え時のフローチャート（図４の続き）。
【符号の説明】
【００１７】
０００３…ファームウェアイメージ、１００…フラッシュメモリ、１０１…エントリブロック、１０２…モジュール１、１０３…モジュール２、１０４…モジュール３、１０５…空き領域、１０６…ファームウェアエントリポイント、１０７…領域管理テーブル、１０８…バージョン構成情報、１０９…カレントファームウェアバージョン、１１０…エントリポイント判定処理。
【図１】
2005321843.tif 000003
【図２】
2005321843.tif 000004
【図３】
2005321843.tif 000005
【図４】
2005321843.tif 000006
【図５】
2005321843.tif 000007