JP2011198357A - 処理装置および書込方法 - Google Patents

Abstract

【課題】ブートローダによるファイルの読み書きの処理遅延を短縮する技術を提供する。
【解決手段】取得部１３０は、ファイルを複数のブロックに分割して記憶可能な記憶装置から、各ブロックのアドレスが示された管理情報を取得する。生成部１３２は、取得した管理情報から、各ブロックのアドレスを抽出するとともに、アドレスが連続したブロックを連続領域として集約することによって、各連続領域に対する開始アドレスとサイズとが示されたテーブルを生成する。読出部１３４は、不揮発性メモリに記憶されたファイルを読み出す。分割部１３６は、読み出したファイルを複数のブロックに分割する。書込部１３８は、テーブルをもとに、開始アドレスからサイズにわたった連続領域ごとに、管理情報に示されたアドレスを維持させるように、分割したファイルを記憶装置に書き込む。
【選択図】図７

Description

本発明は、書込技術に関し、記憶媒体へファイルを書き込む処理装置および書込方法に関する。

コンピュータには、一般的にオペレーティングシステムが搭載されており、各種のソフトウエアプログラムは、このオペレーティングシステムにもとづいて動作される。コンピュータの起動時には、ＢＩＯＳ（Ｂａｓｉｃ Ｉｎｐｕｔ Ｏｕｔｐｕｔ Ｓｙｓｔｅｍ）がブートローダをＲＡＭにコピーして起動させ、ブートローダがハードディスクドライブ（ＨＤＤ）に記憶されたオペレーティングシステムのイメージファイルをＲＡＭに読み込むことによって、オペレーティングシステムが動作可能になる。ここで、ブートローダによるオペレーティングシステムのイメージの読込では、ファイルアロケーションテーブルが終始参照される。しかしながら、ファイルアロケーションテーブルを参照した読込は、一般的に高速に実行できるものではないので、オペレーティングシステムの起動時間の短縮が妨げられていた（例えば、特許文献１参照）。

特開２００４−２４６７８７号公報

ファームウエアもＨＤＤに記憶されうる。例えば、チューナやネットワークにてダウンロードしたファームウエアや、着脱可能な記憶媒体からコピーしたファームウエアが、一時的にＨＤＤに格納される。ここで、ＨＤＤに記憶されたファームウエアが、ＦＬＡＳＨ ＲＯＭなどの不揮発性メモリに書き込まれることによって、ファームウエアが更新される。ＨＤＤへのファームウエアの格納、不揮発性メモリへのファームウエアの書込は、アプリケーションプログラムでも可能である。しかしながら、不揮発性メモリへの書き込みに関しては、処理途中の停電や電源引き抜き等が発生すると、次回、アプリケーションを起動できなくなってしまうので、復帰処理も含めると、ブートローダが行うことが望ましい。

一方、アプリケーションプログラムがファイルシステム上でファームウエアを格納したとしても、ファイルシステムに対応しないブートローダは、ブロックアドレスを指定して、ファームウエアを直接読み出さなければならない。具体的に説明すると、ブートローダは、ファイルシステム情報を解析する。ｅｘｔ２の場合、ファイルシステム情報は、スーパーブロック、ファイルディスクリプタ等に相当する。これにつづいて、ブートローダは、ディレクトリエントリをサーチしながら、ファームウエアの先頭アドレスを抽出し、その後、必要なファイルの中身、もしくはその一部を読み出す。

ＣＤ−ＲＯＭ等で使用されるＩＳＯ９６６０ファイルシステムでは、ファイルの先頭アドレスさえ抽出できれば、ファイルの中身のブロックアドレスが連続しているので、適当に読み出し単位を区切って読み出せばよい。しかしながら、ｅｘｔ２の場合、ファイルの中身がブロックアドレスが連続しておらず、データの間に不定期にｉノードが含まれている。そのため、ファイルシステムを使用しないブートローダは、１ブロックごとに、ｉノードによって示されるアドレスを抽出することによって、ファイルを読み出す。ｉノードを読む度に、シークアクセスのオーバーロードが発生し、処理に時間がかかってしまう。このような課題は、読み出し時だけでなく、書き込み時にも同様に存在する。

旧バージョンのファームウエア、あるいはその一部をＨＤＤに記憶させたい場合、ファイルシステムの規則にしたがって作成されたファイルが更新されると、作成されるファイルのブロックアドレスは、毎回変わってしまう。そのため、読み書きの対象となるブロックアドレスが確定せず、結局、ブートローダにファイルシステム相当の処理を組み込むことが必要とされる。その結果、ブートローダのコード量が増大してしまう。これは、リソースの限られた組み込み機器にとって、好ましくない。これの回避策として、ファイルシステムを使用せずに運用するという方法もあるが、逆に、アプリケーションプログラムからファイルを読み書きできなくなるだけでなく、他のファイルを記憶できなくなる。

本発明はこうした状況に鑑みてなされたものであり、その目的は、ブートローダによるファイルの読み書きの処理遅延を短縮する技術を提供することである。

上記課題を解決するために、本発明のある態様の処理装置は、ファイルを複数のブロックに分割して記憶可能な記憶装置から、ファイルを構成する各ブロックのアドレスが示された管理情報を取得する取得部と、取得部において取得した管理情報から、各ブロックのアドレスを抽出するとともに、アドレスが連続したブロックを連続領域として集約することによって、各連続領域に対する開始アドレスとサイズとが示されたテーブルを生成する生成部と、不揮発性メモリに記憶されたデータを読み出す読出部と、生成部において生成したテーブルをもとに、データを、開始アドレスからサイズで決定される終了アドレスまでにわたった連続領域ごとに分割し、分割したデータを、管理情報に示されたファイルを構成する各ブロックのアドレスを維持させるように記憶装置に書き込む書込部と、を備える。

この態様によると、記憶装置から、連続領域に対応した開始アドレスとサイズが示されたテーブルを作成し、テーブルにしたがって、記憶装置にファイルを書き込むので、書込時間を短縮できる。

取得部は、ファイルが複数のブロックに分割して記憶された記憶装置から、各ブロックのアドレスが示された管理情報を再取得し、生成部は、取得部において再取得した管理情報から、各ブロックのアドレスを抽出するとともに、アドレスが連続したブロックを連続領域として再集約することによって、各連続領域に対する開始アドレスとサイズとが示されたテーブルを再生成し、読出部は、生成部において再生成したテーブルをもとに、開始アドレスからサイズで決定される終了アドレスまでにわたった連続領域ごとに、記憶装置に分割して記憶されたファイルを構成する各ブロックのデータを読み出し、書込部は、読出部において読み出した各ブロックのデータを不揮発性メモリに書き込んでもよい。この場合、記憶装置に記憶されたファイル内の連続領域に対応した開始アドレスとサイズが示されたテーブルを再作成し、テーブルにしたがって読み出し処理を実行するので、更新時間を短縮できる。

書込部は、分割したデータを記憶装置に書き込む際に、記憶装置に記憶されたファイル情報のうち、属性、ファイル名、更新日時の少なくともひとつを更新してもよい。この場合、属性、ファイル名、更新日時の少なくともひとつを更新するので、更新完了した証拠を残すことができる。

本発明の別の態様もまた、処理装置である。この装置は、第１のファームウエアプログラムが複数のブロックに分割して記憶された記憶装置から、各ブロックのアドレスが示された管理情報を取得する取得部と、取得部において取得した管理情報から、各ブロックのアドレスを抽出するとともに、アドレスが連続したブロックを連続領域として集約することによって、各連続領域に対する開始アドレスとサイズとが示されたテーブルを生成する生成部と、生成部において生成したテーブルをもとに、開始アドレスからサイズで決定される終了アドレスまでにわたった連続領域ごとに、記憶装置に分割して記憶された第１のファームウエアプログラムを読み出す読出部と、読出部において読み出した第１のファームウエアプログラムによって、不揮発性メモリに記憶された第２のファームウエアプログラムを更新する書込部と、を備える。

この態様によると、記憶装置に記憶された第１のファームウエアプログラム内の連続領域に対応した開始アドレスとサイズが示されたテーブルを作成し、テーブルにしたがって読み出し処理を実行するので、更新時間を短縮できる。

読出部は、第１のファームウエアプログラムの一部を読み出し対象とする場合、生成部において生成したテーブルをもとに、読み出し対象に対応したブロックだけ読み出す。この場合、連続領域のうち、読み出し対象に対応したブロックだけを読み出すので、第１のファームウエアプログラムの一部を読み出し対象とする場合にも対応できる。

生成部は、既に生成したテーブルを再利用することによって、テーブルの生成を省略してもよい。この場合、既に生成したテーブルを再利用するので、処理期間を短縮できる。

本発明のさらに別の態様は、書込方法である。この方法は、ファイルを複数のブロックに分割して記憶可能な記憶装置から、ファイルを構成する各ブロックのアドレスが示された管理情報を取得するステップと、取得した管理情報から、各ブロックのアドレスを抽出するとともに、アドレスが連続したブロックを連続領域として集約することによって、各連続領域に対する開始アドレスとサイズとが示されたテーブルを生成するステップと、不揮発性メモリに記憶されたデータを読み出すステップと、生成したテーブルをもとに、データを、開始アドレスからサイズで決定される終了アドレスまでにわたった連続領域ごとに分割し、分割したデータを、管理情報に示されたファイルを構成する各ブロックのアドレスを維持させるように記憶装置に書き込むステップと、を備える。

本発明のさらに別の態様もまた、書込方法である。この方法は、第１のファームウエアプログラムが複数のブロックに分割して記憶された記憶装置から、各ブロックのアドレスが示された管理情報を取得するステップと、取得した管理情報から、各ブロックのアドレスを抽出するとともに、アドレスが連続したブロックを連続領域として集約することによって、各連続領域に対する開始アドレスとサイズとが示されたテーブルを生成するステップと、生成したテーブルをもとに、開始アドレスからサイズで決定される終了アドレスまでにわたった連続領域ごとに、記憶装置に分割して記憶された第１のファームウエアプログラムを読み出すステップと、読み出した第１のファームウエアプログラムによって、不揮発性メモリに記憶された第２のファームウエアプログラムを更新するステップと、を備える。

なお、以上の構成要素の任意の組合せ、本発明の表現を方法、装置、システム、記録媒体、コンピュータプログラムなどの間で変換したものもまた、本発明の態様として有効である。

本発明によれば、ブートローダによるファイルの読み書きの処理遅延を短縮できる。

本発明の実施例１に係る処理装置の構成を示す図である。 図１のＨＤＤにおけるｅｘｔ２ファイルシステムの概要を示す図である。 図１のＨＤＤにおけるｉノードテーブルとブロックアドレスの概要を示す図である。 図１のＨＤＤにおけるブロックアドレス上のファイルとｉノードの関係を示す図である。 図１のＨＤＤの構成を示す図である。 図１のＨＤＤの読み出し単位ブロック数と読み出し時間の関係を示す図である。 図１のブートローダの構成を示す図である。 図７の生成部において生成される連続領域の概要を示す図である。 図７の生成部において生成されるテーブルを示す図である。 図７の読出部における始端と終端によるスタートアドレスとサイズの調整の概念図である。 図７のブートローダによる書込手順を示すフローチャートである。 図７の生成部におけるテーブルの作成手順を示すフローチャートである。 図７の生成部におけるブロックアドレスの抽出手順を示すフローチャートである。 本発明の実施例２に係るブートローダによる書込手順を示すフローチャートである。 本発明の実施例３に係るブートローダによる書込手順を示すフローチャートである。 本発明の実施例４に係るブートローダによる書込手順を示すフローチャートである。 本発明の実施例５に係るブートローダによる書込手順を示すフローチャートである。 図１７につづくブートローダによる書込手順を示すフローチャートである。 本発明の実施例６に係るブートローダによる書込手順を示すフローチャートである。

（実施例１）
本発明を具体的に説明する前に、まず概要を述べる。本発明の実施例は、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）に記憶されたファームウエアプログラムによって、不揮発性メモリに記憶されたファームウエアプログラムを更新するためのブートローダに関する。ここでは、一例として、ＨＤＤに使用されるファイルシステムが、ｅｘｔ２であるとする。ｅｘｔ２において、ファームウエアプログラムは、複数のブロックに分割されて記憶される。なお、複数のブロックが連続しているとは限らない。詳細は後述するが、ＨＤＤからのファームウエアプログラムの読出し期間を短くするためには、シークの繰り返し回数を少なくし、連続したブロックを一度に読み出すことが有効である。

一方、ブートローダは、ＨＤＤに記憶されたファームウエアプログラムのブロックアドレスを予め認識していないので、ブロックアドレスが示されたｉノードを取得しなければならない。このｉノードは、ＨＤＤ内において分散して格納されるので、ｉノードからブロックアドレスを取得しながら、ファームウエアプログラムを読み出す場合、連続したブロックを一度に読み出すことが困難になる。そのため、読出し速度の高速化が困難になる。これに対応するために、実施例に係るブートローダは、次の処理を実行する。

ブートローダは、ファームウエアプログラムを読み出す前に、ｉノードからブロックアドレスを取得し、連続したブロック（以下、「連続領域」という）に関するテーブルを生成する。当該テーブルには、各連続領域のスタートアドレスとサイズとが示されている。ブートローダは、テーブルを参照しながら、連続したブロックを一度に読み出すことによって、ＨＤＤからのファームウエアプログラムの読出しを高速化させる。

図１は、本発明の実施例１に係る処理装置１００の構成を示す。処理装置１００は、プロセッサ１０２、ＨＤＤ１０４、揮発性メモリ１０６、不揮発性メモリ１０８、着脱式メモリ１１０、チューナ１１２を含む。また、プロセッサ１０２は、ＣＰＵ（中央処理装置）１１４、ブートローダ１１６を含む。さらに、処理装置１００は、ネットワーク１１８を介してサーバ１２０に接続される。

プロセッサ１０２は、集積回路等にて実現される。プロセッサ１０２は、ＣＰＵ１１４と、ブートローダ１１６のほか、多種のドライバ、専用処理モジュールを統合している。プロセッサ１０２は、多様なデバイスやメディアとアクセス可能である。不揮発性メモリ１０８は、ＦＬＡＳＨ ＲＯＭ、ＥＥＰＲＯＭ等であり、ＣＰＵ１１４が処理すべきプログラムを格納する。また、不揮発性メモリ１０８は、ファームウエアプログラムを記憶する。揮発性メモリ１０６は、ＳＤＲＡＭ等で構成された実処理用のメモリである。ブートローダ１１６がプログラムを不揮発性メモリ１０８から揮発性メモリ１０６へ読み込んで起動させることにより、ＣＰＵ１１４がプログラムを処理可能になる。なお、ブートローダ１１６の処理は、段階的に分けることができるので、一部がプログラムに含まれる場合もある。

チューナ１１２は、ＢＳ／ＣＳ／地上波デジタル／地上波アナログ等を受信可能なモジュールであり、プロセッサ１０２による制御によって、受信データを出力する。ＨＤＤ１０４は、各種のプログラムや、チューナ１１２によって受信したデータ等を蓄積する。ここで、ＨＤＤ１０４は、不揮発性メモリ１０８に記憶されたファームウエアプログラムよりも新しいバージョンのファームウエアプログラムを記憶する。プロセッサ１０２には、着脱式メモリ１１０のドライバが含まれており、着脱式メモリ１１０に対してデータの読み書きが可能である。また、プロセッサ１０２は通信用のドライバを有しており、インターネット、イントラネット等のネットワーク１１８を介して、遠隔地のサーバ１２０と通信する。

不揮発性メモリ１０８には、一般的に、工場出荷時に、ファームウエアプログラム等のプログラムが書き込まれている。プログラムの内容の修正や性能向上を目的として、出荷後に、ユーザの使用環境において、プログラムの更新がなされる。プログラム更新の一例が、衛星放送を利用したオンエアダウンロードによる更新である。これでは、番組表等と同様に、プログラムの更新データがチューナ１１２によってダウンロードされ、データを蓄積後、プログラム更新がなされる。同様に遠隔地からダウンロードする方法として、遠隔地のサーバ１２０から、ネットワーク１１８を経由してプログラムの更新データがダウンロードされ、データを蓄積後、プログラム更新がなされてもよい。さらに、他の方法として、着脱式メモリ１１０に記憶されたデータがコピーされ、データを蓄積後、プログラム更新がなされてもよい。

本実施例は、プログラム更新として、ファームウエアプログラムの更新を対象とする。ファームウエアプログラムの更新における処理は、更新データを取得して蓄積するための処理（以下、「蓄積処理」という）、蓄積した更新データを読み出して、不揮発性メモリ１０８に書き込む処理（以下、「書込処理」という）に分類される。前述のごとく、更新データは、ＨＤＤ１０４に蓄積される。蓄積処理は、オンエアダウンロードやネットワーク１１８経由のダウンロードなど、アプリケーションプログラムの動作中になされるので、蓄積処理自体も、アプリケーションプログラムによってなされる。着脱式メモリ１１０からのデータコピーも、アプリケーションプログラムの動作中であれば、ファイルをコピーするだけですむので、アプリケーションプログラムによる蓄積処理が適している。

一方、書込処理は、アプリケーションプログラムでも実現可能ではあるが、アプリケーションプログラムは更新データに含まれる。そのため、書き込み中に停電や、ユーザによる電源引き抜きが発生すると、次回、ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）やアプリケーションプログラムが正常に起動しなくなるおそれがある。結果として、書き込みの再試行が不可能となり、２度と復帰しなくなってしまう。そのため、蓄積した更新データを読み出して、不揮発性メモリ１０８に書き込む処理は、ＯＳやアプリケーションに依存しないブートローダ１１６によってなされることが望ましい。なお、書込処理をブートローダ１１６が行う場合、前処理である更新データを取得して蓄積する処理との間には、リブート処理が伴うため、データの蓄積場所は、不揮発性かつ、更新用のソフトウエアプログラムを格納可能な容量が必要になる。そのため、ＨＤＤ１０４が、更新用のソフトウエアプログラムの蓄積場所に適している。

図２は、ＨＤＤ１０４におけるｅｘｔ２ファイルシステムの概要を示す。ＯＳにＬｉｎｕｘを用いる場合、ブロックファイルシステムとしては、ｅｘｔ２が使用されることが多い。ｅｘｔ２は、Ｆａｓｔ Ｆｉｌｅ Ｓｙｓｔｅｍをもとに開発されており、ＵＮＩＸ（登録商標）で伝統的に用いられてきた「ブロック管理アルゴリズム」をベースとしている。ｅｘｔ２では、１０２４、２０４８、４０９６ｂｙｔｅｓのいずれかでブロック単位が構成され、複数のブロックが「ブロックグループ」にまとめて管理される。図２では、ブロックグループの構造が示される。図２の左側は、図１のＨＤＤ１０４内に形成されたパーティションを示し、図２の中央は、ｅｘｔ２パーティションのレイアウトを示す。図２の右側は、ブロックグループ内のレイアウトをさらに詳細を示す。ここで、スーパーブロックとは、ファイルシステムに関する管理情報であり、グループディスクリプタとは、グループ内の情報であり、データブロックビットマップとは、データブロックの情報である。また、ｉノードテーブルは、ファイル／ディレクトリに関する情報を保持するｉノードを格納し、データブロックは、実際のデータを保持する。

図１のブートローダ１１６は、スーパーブロックやグループディスクリプタの情報でファイルシステムの情報を得た後、ディレクトリエントリ内をサーチし、目的のファイルに対応したｉノードテーブルの情報を得る。ｉノードテーブルにもとづいて、データブロックのメモリアドレスを求めることによって、実際のファイル内データの読み込みが可能になる。データブロックのサイズは、ほかのブロックと同じ１０２４、２０４８、４０９６ｂｙｔｅｓのいずれかの値である。データブロックのサイズが２０４８ｂｙｔｅで、ファイルサイズが２００Ｋｂｙｔｅｓであるファイルの参照には、１００個のデータブロックが必要になる。しかしながら、１００個のデータブロックに対して１００個のアドレスを保持する場合、情報量が増大してしまうので、ｅｘｔ２では効率的にアドレス範囲を使用するために間接ブロックを作成し、間接ポインタによって参照できるようにしている。

図３は、ＨＤＤ１０４におけるｉノードテーブルとブロックアドレスの概要を示す。ｉノードがもつデータブロック参照用の配列は１５個であり、ｅｘｔ２では、そのうち１２個を「直接参照」、残りの３つをそれぞれ「一段間接参照」「二段間接参照」「三段間接参照」用に使用する。これにより、ｅｘｔ２は、複数のデータブロックを必要とする容量の大きいファイルを効率的に扱う。それぞれの参照方法で、表現可能なファイルサイズは、計算上、次のようになる。直接参照の計算式は、「ブロックサイズ×１２個」である。ブロックサイズが１０２４ｂｙｔｅｓ、２０４８ｂｙｔｅｓ、４０９６ｂｙｔｅｓの場合、それぞれファイルサイズは、１２Ｋｂｙｔｅｓ、２４Ｋｂｙｔｅｓ、４８Ｋｂｙｔｅｓになる。

一段間接参照では、間接参照用に「ブロックサイズ÷４」個分使用できる。これは、ブロックポインタの大きさ［ｂｙｔｅ］に相当する。そのため、ファイルサイズに換算すると、「ブロックサイズ÷４＊ブロックサイズ」になり、ブロックサイズが１０２４ｂｙｔｅｓ、２０４８ｂｙｔｅｓ、４０９６ｂｙｔｅｓの場合、それぞれのファイルサイズは、２５６Ｋｂｙｔｅｓ、１Ｍｂｙｔｅｓ、４Ｍｂｙｔｅｓになる。二段間接参照では、ファイルサイズに換算すると、「（（ブロックサイズ÷４）^２）×ブロックサイズ」になる。そのため、ブロックサイズが１０２４ｂｙｔｅｓ、２０４８ｂｙｔｅｓ、４０９６ｂｙｔｅｓの場合、それぞれのファイルサイズは、６４Ｍｂｙｔｅｓ、５１２Ｍｂｙｔｅｓ、４Ｇｂｙｔｅｓになる。図１の不揮発性メモリ１０８に書き込むべき更新用プログラムのファイルサイズが数十〜数百Ｍｂｙｔｅｓである場合、二段間接参照の使用が望ましい。

図４は、ＨＤＤ１０４におけるブロックアドレス上のファイルとｉノードの関係を示す。ｉノード自体は、ＨＤＤ１０４において、まとまった領域に格納されておらず、データブロック内に形成される。そのため、間接参照を使用した場合、元ファイルのデータに連続性がなくなる。これはカーネルが、ｉノードとそれに対応するデータブロックを読み込む際にディスクヘッドのシークを減らすために、ｉノードをデータブロックと同じグループ内に割り当てようとするためである。アドレス表現が４ｂｙｔｅｓの場合、１ブロック中に格納出来るアドレス数は、「ブロックサイズ÷４」となる。つまり、計算上、「ブロックサイズ÷４」に１回は、データの中にｉノードを入れないと、全てのアドレスを表現することが出来ない。例えば、２０４８ｂｙｔｅｓの場合、５１２ｂｙｔｅｓに１回はｉノードが埋め込まないと、全てのアドレスを表現することが出来ない。そして、実際には、必ずしも５１２ｂｙｔｅｓではなく、不定期に、より少ない間隔でｉノードが挿入される。さらに、ファイルの位置と、その中に含まれるｉノードの位置は、ファイル生成ごとに更新されるので、特定が困難になる。つまり、図１のブートローダ１１６は、ファイルの先頭データが入っているブロックアドレスを抽出したとしても、ブロックを連続して読み出せず、１ブロックごとに参照を行いながら、データのブロックアドレスを読み出さなければならない。

図５は、ＨＤＤ１０４の構成を示す。同心円状に生成されたトラック１５０に、データを読み書きする単位として、セクタ１５２という領域が形成される。スイングアーム１４４で磁気ヘッド１４６が、ディスク１４０上を移動させられて、データへのアクセスがなされる。この操作をシークと呼び，その所要時間をシーク時間と呼ぶ．同じシリンダ１４８内であればシーク時間がないので、回転待ち時間のみとなるが、シークを伴う場合は、シーク時間を考慮しなければならない。一般的に、ＨＤＤ１０４のデータ読み出し時間は「（平均シーク時間＋平均回転待ち時間＋データ転送時間）×（シークの繰り返し回数）」で計算される。ここで、データの転送時間＜＜（平均シーク時間＋平均回転待ち時間）の関係が成立される。そのため、「シークの繰り返し回数」が少ないほど、全体のデータ読み出し時間は短くなる。また、ひとつのトラック１５０を越えるサイズのファイルを読み出す場合に、連続したアドレスを一度に読み込む方が、ロングシークではなく、１トラックジャンプでアクセスできるので、データ読み出し時間が短くなる。

図６は、ＨＤＤ１０４の読み出し単位ブロック数と読み出し時間の関係を示す。これは、アクセス単位を変更しながら、１２８Ｍｂｙｔｅｓのデータの読み出し時間を計測した結果である。１ブロック単位の読み出しに対して、読み出し単位ブロック数を増やしていくにしたがって、読み出し時間が大きく減少し、１２８Ｍｂｙｔｅｓ付近で飽和している。

図７は、ブートローダ１１６の構成を示す。ブートローダ１１６は、取得部１３０、生成部１３２、読出部１３４、分割部１３６、書込部１３８を含む。取得部１３０は、図１のＨＤＤ１０４におけるｅｘｔ２ファイルシステム上に構成されているスーパーブロックを解析し、ブロックサイズなどの必要な情報を取得する。取得部１３０は、グループディスクリプタを解析し、ｉノードテーブルＩＤなど必要な情報を取得する。取得部１３０は、ディレクトリエントリをサーチし、アップデートファイルのｉノード情報を取得する。

生成部１３２は、更新用のファームウエアプログラムが複数のブロックに分割して記憶されたＨＤＤ１０４から、各ブロックのアドレスが示された管理情報を取得する。生成部１３２は、取得した管理情報、つまりｉノードテーブルの情報と間接参照を用いてファイル内の各ブロックに対応したブロックアドレスを抽出する。生成部１３２は、ブロックアドレスが連続したブロックを連続領域として集約する。図８は、生成部１３２において生成される連続領域の概要を示す。ここで、ブロックアドレスと、連続領域のスタートアドレスとサイズを示すテーブルの関係について補足する。図８は、ファイル内の全ブロックを配列として表現し、それぞれのブロックアドレスとの対応を示したものである。直接参照であるＢｌｏｃｋ［０］からＢｌｏｃｋ［１１］までは、ブロックアドレスも連続しているが、Ｂｌｏｃｋ［１２］からは、ブロックアドレスがひとつずれている。これは、ｉノードの間接参照に使用されているため、０ｘ００００１Ｃ０Ｃが抜けているためである。図７に戻る。

また、生成部１３２は、各連続領域に対するスタートアドレスとサイズとが示されたテーブルを生成する。テーブルは、図１の揮発性メモリ１０６上に配列として構成されてもよいし、ＨＤＤ１０４や不揮発性メモリ１０８に格納されてもよい。図９は、生成部１３２において生成されるテーブルを示す。最初の連続領域は、図８のＢｌｏｃｋ［０］からＢｌｏｃｋ［１１］の範囲となり、対応するスタートアドレスとサイズは、図９の最初の行に示す値になる。第２の連続領域以降も同様であり、結果として、図９のようなテーブルが生成される。図９のテーブルのサイズは、図８のテーブルのサイズよりも格段に小さい。例えば、ファームウエアプログラムのファイルサイズが数十〜数百Ｍｂｙｔｅｓで、ブロックサイズが２０４８ｂｙｔｅｓの場合、２段間接参照で実現でき、概算で１／（２０４８／４）＝１／５１２のテーブルサイズとなる。そのため、図８のテーブルを保持する場合よりも、テーブルを保持するためのリソースが大幅に削減される。図７に戻る。

読出部１３４は、生成部１３２において生成したテーブルをもとに、スタートアドレスからサイズにわたった連続領域ごとに、ＨＤＤ１０４に分割して記憶された更新用のファームウエアプログラムを読み出す。つまり、読出部１３４は、連続領域に含まれた複数のブロックをまとめて読み出す。読出部１３４は、読み出したファームウエアプログラムを揮発性メモリ１０６に一時的に記憶する。このとき、更新用のファームウエアプログラム内の一部を切り出す場合、切り出す一部の始端と終端が連続領域の区切りになっているとは限らない。その際、読出部１３４は、始端と終端がどの連続領域に含まれるかを予め検出し、スタートアドレスとサイズを調整する。

例えば、連続領域の途中のブロックが始端である場合、始端に対応したブロックまで、スタートアドレスが後方にずらされる。また、終端についても同様である。つまり、読出部１３４は、更新用のファームウエアプログラムの一部を読み出し対象とする場合、生成部１３２において生成したテーブルをもとに、読み出し対象に対応したブロックだけ読み出す。書込部１３８は、揮発性メモリ１０６から更新用のファームウエアプログラムを読み出して、不揮発性メモリ１０８に書き込む。つまり、書込部１３８は、読出部１３４において読み出した更新用のファームウエアプログラムによって、不揮発性メモリ１０８に記憶されたこれまでのファームウエアプログラムを更新する。なお、分割部１３６は、実施例１において、動作しない。

ファイル内の一部のデータに対して、読み書きする場合、図９のテーブルにおける連続領域の区切りが始端と終端になっているとは限らない。よって、読み書きを開始する前に、予め、始端と終端がどの連続領域に含まれるかを検出し、各々のスタートアドレスとサイズを調整することで対応する。図１０は、読出部１３４における始端と終端によるスタートアドレスとサイズの調整の概念図である。始端と終端における、スタートアドレスとサイズの調整を行うためには、まず、図１０の右側に示すように、連続領域を順番につなげていき、仮想のアドレスを作成する（実際には、間にｉ−ｎｏｄｅが入るので、実アドレスとは異なる）。その過程において、読み出し対象のデータの（ファイル先頭基準における）先頭位置を示すｓｔａｒｔ、および終端位置を示すｅｎｄが、各連続領域の仮想アドレス内に存在するかどうかを検出する。図に示すように、ｓｔａｒｔとｅｎｄを実線で囲んだ領域が読み出したいデータである。この場合のｓｔａｒｔ位置は、Ｅｘｔ［３］に含まれるので、Ｅｘｔ［３］につき、スタートアドレスを後ろにずらし、かつサイズを小さくすることで、補正が可能となる。同様に、ｅｎｄ位置については、Ｅｘｔ［１１２］に含まれるので、Ｅｘｔ［１１２］につき、サイズを小さくすることで、補正が可能となる。

この構成は、ハードウエア的には、任意のコンピュータのＣＰＵ、メモリ、その他のＬＳＩで実現でき、ソフトウエア的にはメモリにロードされたプログラムなどによって実現されるが、ここではそれらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックがハードウエアのみ、ソフトウエアのみ、またはそれらの組合せによっていろいろな形で実現できることは、当業者には理解されるところである。

以上の構成によるブートローダ１１６の動作を説明する。図１１は、ブートローダ１１６による書込手順を示すフローチャートである。取得部１３０は、ｅｘｔ２ファイルシステム上に構成されているスーパーブロックの解析を行い（Ｓ１０）、ブロックサイズなどの必要な情報を取得する。取得部１３０は、グループディスクリプタの解析を行い（Ｓ１２）、ｉノードテーブルＩＤなど必要な情報を取得する。取得部１３０は、ディレクトリエントリをサーチし、アップデートファイルのｉノード情報を取得する（Ｓ１４）。

生成部１３２は、ｉノードテーブルの情報と間接参照を用いてファイル内の各ブロックに対応したブロックアドレスを抽出し、連続領域のスタートアドレスとサイズを示すテーブルを作成する（Ｓ１６）。読出部１３４は、連続領域ごとに更新用ファームウエアをＨＤＤ１０４より読み出して、揮発性メモリ１０６に一時格納する（Ｓ１８）。書込部１３８は、揮発性メモリ１０６から更新用ファームウエアを読み出して不揮発性メモリ１０８へ書き込む（Ｓ２０）。

図１２は、生成部１３２におけるテーブルの作成手順を示すフローチャートである。生成部１３２は、ファイルの先頭に位置する先頭ブロックアドレスを抽出する（Ｓ４０）。生成部１３２は、連続領域のスタートアドレスに、抽出した先頭ブロックアドレスの値を入れる（Ｓ４２）。生成部１３２は、パラメータ（連続領域番号、連続領域サイズ、ブロック数カウンタ）を初期化する（Ｓ４４）。ブロック数カウンタｍがブロックサイズを超えていなければ（Ｓ４６のＹ）、生成部１３２は、ブロックアドレスを抽出する（Ｓ４８）。

生成部１３２は、ブロックアドレスが、ひとつ前のデータのブロックアドレスと連続しているかを確認し、連続している場合には（Ｓ５０のＹ）、サイズのみインクリメントする（Ｓ５４）。連続していない場合には（Ｓ５０のＮ）、生成部１３２は、連続領域番号をインクリメントするとともに、スタートアドレスを現在対象としているブロックアドレスで更新し、サイズを初期化（１）する（Ｓ５２）。生成部１３２は、ブロック数カウンタをインクリメントした（Ｓ５６）後にステップ４６に戻る。ブロック数カウンタｍがブロックサイズを超えれば（Ｓ４６のＮ）、処理は終了する。

図１３は、生成部１３２におけるブロックアドレスの抽出手順を示すフローチャートである。これは、図１２のステップ４０、ステップ４８でのブロックアドレスの抽出に相当する。図１１のステップ１４にて得られたｉノード情報により、図３に示したｉノードテーブルの中から、対象のｉノードの抽出が可能であるが、説明を明瞭にするため、この中の参照情報を抜き出したものをｉ＿ｎｏｄｅ［ｉ］ ０＜ｉ＜１５とする（Ｓ７０）。ｉ＜１２であれば（Ｓ７２のＹ）、生成部１３２は、直接参照を行い、ブロックアドレスを抽出する（Ｓ７４）。ｉ＜１２でなく（Ｓ７２のＮ）、ｉ＝１２であれば（Ｓ７６のＹ）、生成部１３２は、一段間接参照行ってブロックアドレスを抽出する（Ｓ７８）。ｉ＝１２でなく（Ｓ７６のＮ）、ｉ＝１３であれば（Ｓ８０のＹ）、生成部１３２は、二段間接参照を行い、ブロックアドレスを抽出する（Ｓ８２）。ｉ＝１３でなければ（Ｓ８０のＮ）、つまりｉ＝１４であれば、生成部１３２は、三段間接参照を行い、ブロックアドレスを抽出する（Ｓ８４）。

本発明の実施例によれば、ＨＤＤに格納された更新用のファームウエアプログラム内の連続領域に対応したスタートアドレスとサイズとが示されたテーブルを作成し、テーブルにしたがって読み出し処理を実行するので、ファームウエアプログラムの更新時間を短縮できる。また、テーブルを作成するので、ファイルシステムをもたないブートローダが、不揮発性メモリに格納されたファームウエアプログラムを更新する場合であっても、更新時間を短縮できる。また、ＨＤＤからの読み出しサイズは、「ブロックサイズ÷４」に近くなるので、読出しを高速にできる。また、ファイルシステム上でファイルの再配置等が行われた場合でも、柔軟に追従するので、性能への影響を低減できる。また、連続領域のテーブルの情報量は、ブロックアドレスについてのテーブルの情報量よりも小さいので、処理の効率を向上できる。

（実施例２）
本発明の実施例２は、実施例１と同様に、ファームウエアプログラムを書き込むためのブートローダに関する。一方、実施例２は、実施例１と異なり、不揮発性メモリに記憶されたファームウエアプログラムをＨＤＤに一時格納する場合に相当する。ここで、ＨＤＤへの一時格納は、ファームウエアプログラムのバックアップを目的としてなされる。つまり、実施例２と実施例１では、ファームウエアプログラムを読み出すべき記憶媒体と、ファームウエアプログラムを書き込むべき記憶媒体とが反対になる。実施例２に係る処理装置１００は、図１と同様のタイプであり、実施例２に係るブートローダ１１６は、図７と同様のタイプである。ここでは、実施例１との差異を中心に説明する。

なお、ＨＤＤ１０４には、バックアップ用のファームウエアプログラム、もしくはバックすべきファームウエアプログラムと同サイズのファイルが、ファイルシステム上において、アプリケーションプログラム等によって格納されている。取得部１３０は、図１のＨＤＤ１０４に対して、スーパーブロックおよびグループディスクリプタを解析する。さらに、取得部１３０は、ディレクトリエントリをサーチし、ＨＤＤ１０４に既に記憶しているファイルのｉノード情報を取得する。

生成部１３２は、バックアップ用のファームウエア等のファイルを複数のブロックに分割して記憶可能なＨＤＤ１０４から、各ブロックのアドレスが示された管理情報を取得する。生成部１３２は、ｉノードテーブルの情報と間接参照を用いてファイル内の各ブロックに対応したブロックアドレスを抽出する。生成部１３２は、ブロックアドレスが連続したブロックを連続領域として集約する。生成部１３２は、各連続領域に対するスタートアドレスとサイズとが示されたテーブルを生成する。読出部１３４は、不揮発性メモリ１０８に記憶されたファームウエアプログラムを読み出し、揮発性メモリ１０６に一時格納する。読み出したファームウエアプログラムが、これからバックアップすべきファームウエアプログラムである。

分割部１３６は、揮発性メモリ１０６に記憶したファームウエアプログラムを分割する。また、分割部１３６は、生成部１３２において集約した連続領域に適合するように、分割した複数のブロックを集約する。このような処理によって、生成部１３２において生成した各連続領域に対応するように、ファームウエアプログラムが複数に分割される。書込部１３８は、生成部１３２において生成したテーブルをもとに、スタートアドレスからサイズにわたった連続領域ごとに、分割部１３６において分割したファームウエアプログラムをＨＤＤ１０４に書き込む。つまり、連続領域のアドレスを変更させないように、複数に分割されたファームウエアプログラムがＨＤＤ１０４に書き込まれる。その結果、ｉノードテーブルのような管理情報に示されたブロックアドレスも変化されない。ＨＤＤ１０４にファームウエアプログラムを書き込むことが、ファームウエアプログラムをバックアップすることに相当する。

図１４は、本発明の実施例２に係るブートローダ１１６による書込手順を示すフローチャートである。取得部１３０は、ｅｘｔ２ファイルシステム上に構成されているスーパーブロックの解析を行い（Ｓ１００）、ブロックサイズなどの必要な情報を取得する。取得部１３０は、グループディスクリプタの解析を行い（Ｓ１０２）、ｉノードテーブルＩＤなど必要な情報を取得する。取得部１３０は、ディレクトリエントリをサーチし、バックアップ用ファイルのｉノード情報を取得する（Ｓ１０４）。

生成部１３２は、ｉノードテーブルの情報と間接参照を用いてファイル内の各ブロックに対応したブロックアドレスを抽出し、連続領域のスタートアドレスとサイズを示すテーブルを作成する（Ｓ１０６）。読出部１３４は、不揮発性メモリ１０８からファームウエアを揮発性メモリ１０６へ読み出す（Ｓ１０８）。書込部１３８は、揮発性メモリ１０６からバックアップ用ファームウエアを読み出して、連続領域ごとに、ＨＤＤ１０４でのバックアップファイルに書き込む（Ｓ１１０）。

本発明の実施例によれば、予めアプリケーションプログラム等によって生成した同サイズのファイルに対して、連続領域に対応したスタートアドレスとサイズが示されたテーブルを作成し、テーブルにしたがって書き込み処理を実行するので、バックアップ時間を短縮できる。また、テーブルにしたがって書き込み処理を実行するので、ＨＤＤ内にバックアップ用データを記憶する際にも、書込処理を高速にできる。また、テーブルにしたがって書き込み処理を実行するので、ファイルシステムを用いたアプリケーションプログラムの処理と共存できる。また、ファイルシステムをもたないブートローダによるファイルの書込みは、困難であるが、先に配置した同サイズのファイルのブロックアドレスを利用して書込みを行うので、ファイルシステム上のアプリケーションプログラムの処理との共存を実現できる。

なお、上記説明では、分割部１３６と書込部１３８とが分離している場合について説明したが、実際の処理においては、揮発性メモリ１０６とＨＤＤ１０４の間でデータ転送（コピー）するＡＰＩ(Application Program Interface)、もしくは、関数を用意して、指定するアドレスをずらしていくことにより、実現してもよいことは、勿論である。

（実施例３）
本発明の実施例３は、実施例２の動作につづいて、実施例１の動作を実行する場合に相当する。つまり、実施例３は、実施例２の動作によってＨＤＤに記憶されたバックアップファイルを利用し、不揮発性メモリのファームウエアプログラムを更新する場合に相当する。このようなファームウエアプログラムの更新は、ファームウエアプログラムのリカバリーともいえる。実施例３に係る処理装置１００は、図１と同様のタイプであり、実施例３に係るブートローダ１１６は、図７と同様のタイプである。ここでは、これまでの実施例との差異を中心に説明する。

ＨＤＤ１０４には、バックアップ用のファームウエアプログラムが、ファイルシステム上において、実施例２での処理によって格納されている。取得部１３０は、図１のＨＤＤ１０４におけるｅｘｔ２ファイルシステム上に構成されているスーパーブロックおよびグループディスクリプタを解析する。取得部１３０は、ディレクトリエントリをサーチし、バックアップ用ファイルのｉノード情報を再取得する。つまり、取得部１３０は、バックアップ用のファームウエアプログラムが複数のブロックに分割して記憶されたＨＤＤ１０４から、各ブロックのアドレスが示された管理情報を再取得する。

生成部１３２は、取得部１３０において取得した管理情報、つまりｉノードテーブルの情報と間接参照を用いてバックアップ用のファームウエアプログラム内の各ブロックに対応したブロックアドレスを抽出する。生成部１３２は、ブロックアドレスが連続したブロックを連続領域として集約する。生成部１３２は、各連続領域に対するスタートアドレスとサイズとが示されたテーブルを再生成する。読出部１３４は、生成部１３２において再生成したテーブルをもとに、スタートアドレスからサイズにわたった連続領域ごとに、ＨＤＤ１０４に分割して記憶されたバックアップ用のファームウエアプログラムを読み出す。読出部１３４は、読み出したファームウエアプログラムを揮発性メモリ１０６に一時的に記憶する。

書込部１３８は、揮発性メモリ１０６からバックアップ用のファームウエアプログラムを読み出して、不揮発性メモリ１０８に書き込む。つまり、書込部１３８は、読出部１３４において読み出したバックアップ用のファームウエアプログラムによって、不揮発性メモリ１０８に記憶されたこれまでのファームウエアプログラムをリカバリーする。なお、分割部１３６は、実施例３において、動作しない。

図１５は、本発明の実施例３に係るブートローダ１１６による書込手順を示すフローチャートである。取得部１３０は、ｅｘｔ２ファイルシステム上に構成されているスーパーブロックの解析を行い（Ｓ１３０）、ブロックサイズなどの必要な情報を取得する。取得部１３０は、グループディスクリプタの解析を行い（Ｓ１３２）、ｉノードテーブルＩＤなど必要な情報を取得する。取得部１３０は、ディレクトリエントリをサーチし、アップデートファイルのｉノード情報を取得する（Ｓ１３４）。

生成部１３２は、ｉノードテーブルの情報と間接参照を用いてファイル内の各ブロックに対応したブロックアドレスを抽出し、連続領域のスタートアドレスとサイズを示すテーブルを作成する（Ｓ１３６）。読出部１３４は、連続領域ごとにバックアップ用ファームウエアをＨＤＤ１０４より読み出して、揮発性メモリ１０６に一時格納する（Ｓ１３８）。書込部１３８は、揮発性メモリ１０６からバックアップ用ファームウエアを読み出して不揮発性メモリ１０８へ書き込む（Ｓ１４０）。

本発明の実施例によれば、ＨＤＤに格納された更新用のファームウエアプログラム内の連続領域に対応したスタートアドレスとサイズとが示されたテーブルを作成し、テーブルにしたがって読み出し処理を実行するので、ファームウエアプログラムのリカバリー時間を短縮できる。また、テーブルを作成するので、ファイルシステムをもたないブートローダが、不揮発性メモリに格納されたファームウエアプログラムを更新する場合であっても、リカバリー時間を短縮できる。

（実施例４）
本発明の実施例４は、実施例２と同様に、不揮発性メモリに記憶されたファームウエアプログラムをＨＤＤに一時格納する場合に相当する。実施例４では、ファームウエアプログラムをＨＤＤに格納する際に、ファイル情報も更新される。実施例４に係る処理装置１００は、図１と同様のタイプであり、実施例４に係るブートローダ１１６は、図７と同様のタイプである。ここでは、これまでの実施例との差異を中心に説明する。

書込部１３８は、実施例２と同様に、生成部１３２において生成したテーブルをもとに、スタートアドレスからサイズにわたった連続領域ごとに、分割部１３６において分割したファームウエアプログラムをＨＤＤ１０４に書き込む。その際、書込部１３８は、ＨＤＤ１０４に書き込むべきファームウエアプログラムについてのファイル情報のうち、属性、ファイル名、更新日時の少なくともひとつを更新する。

図１６は、本発明の実施例４に係るブートローダ１１６による書込手順を示すフローチャートである。図１６のステップ１６０からステップ１７０は、図１４のステップ１００からステップ１１０と同一である。書込部１３８は、ファイル情報のうち、属性、ファイル名、更新日時の少なくともひとつを更新する（Ｓ１７２）。

本発明の実施例によれば、ファイル情報のうち、属性、ファイル名、更新日時の少なくともひとつを更新するので、更新完了した証拠を残すことができる。また、ファイル情報のうち、属性、ファイル名、更新日時の少なくともひとつを更新することによって、ファイルシステム上のデータを更新するので、アプリケーションプログラムからも更新を確認できる。

（実施例５）
本発明の実施例５は、実施例２において使用したテーブルと、実施例３において使用したテーブルを共通化する場合に相当する。つまり、実施例５は、不揮発性メモリに記憶したファームウエアプログラムをＨＤＤにバックアップファイルとして一時格納させる場合と、ＨＤＤに一時格納したバックアップファイルを利用することによって、不揮発性メモリに記憶したファームウエアプログラムを更新する場合とにおいてテーブルを共通化することに関する。このような処理によって、テーブル作成のための時間を削減することが可能になる。実施例５に係る処理装置１００は、図１と同様のタイプであり、実施例５に係るブートローダ１１６は、図７と同様のタイプである。ここでは、これまでの実施例との差異を中心に説明する。

実施例２と同様に、不揮発性メモリ１０８に記憶されたファームウエアプログラムをＨＤＤ１０４に記憶させる際、取得部１３０は、ＨＤＤ１０４や不揮発性メモリ１０８に、既に生成したテーブルが格納されているかを確認する。テーブルが格納されていなければ、取得部１３０および生成部１３２は、実施例２と同様の処理を実行することによって、テーブルを生成する。一方、テーブルが格納されていれば、取得部１３０および生成部１３２は、実施例２での処理を省略し、読出部１３４は、不揮発性メモリ１０８に記憶されたファームウエアプログラムを読み出し、揮発性メモリ１０６に一時格納する。

実施例３と同様に、ＨＤＤ１０４に記憶されたバックアップ用のファームウエアプログラムを不揮発性メモリ１０８に記憶させる際も、取得部１３０は、ＨＤＤ１０４や不揮発性メモリ１０８に、既に生成したテーブルが格納されているかを確認する。ここで、テーブルは、過去において、不揮発性メモリ１０８に記憶されたファームウエアプログラムをＨＤＤ１０４に記憶させる際、あるいはＨＤＤ１０４に記憶されたファームウエアプログラムを不揮発性メモリ１０８に記憶させる際に生成されいればよい。テーブルが格納されていなければ、取得部１３０および生成部１３２は、実施例３と同様の処理を実行することによって、テーブルを生成する。一方、テーブルが格納されていれば、取得部１３０および生成部１３２は、実施例３での処理を省略し、読出部１３４は、格納されていたテーブルをもとに、スタートアドレスからサイズにわたった連続領域ごとに、ＨＤＤ１０４に分割して記憶されたバックアップ用のファームウエアプログラムを読み出す。このように、生成部１３２は、既に生成したテーブルを再利用することによって、テーブルの生成処理を省略する。

図１７は、本発明の実施例５に係るブートローダ１１６による書込手順を示すフローチャートである。既存のテーブルがあれば（Ｓ１９０のＹ）、読出部１３４は、テーブルを読み出す（Ｓ１９２）。既存のテーブルがなければ（Ｓ１９０のＮ）、取得部１３０は、スーパーブロックを解析する（Ｓ１９４）。ステップ１９４からステップ２０６は、図１４のステップ１００からステップ１１０と同一である。

図１８は、図１７につづくブートローダ１１６による書込手順を示すフローチャートである。既存のテーブルがあれば（Ｓ２２０のＹ）、読出部１３４は、テーブルを読み出す（Ｓ２２２）。既存のテーブルがなければ（Ｓ２２０のＮ）、取得部１３０は、スーパーブロックを解析する（Ｓ２２４）。ステップ２２４からステップ２３６は、図１５のステップ１３０からステップ１４０と同一である。

本発明の実施例によれば、テーブルを共通化することにより、バックアップデータの更新処理時間を短縮できるとともに、バックアップデータを用いたリカバリーの処理時間も短縮できる。また、既存のテーブルを読み出すので、テーブル作成のための時間を削減できる。また、既存のテーブルを読み出すので、処理量を低減できる。

（実施例６）
本発明の実施例６は、実施例１においてテーブルを既に生成している場合、テーブルを新たに生成せずに、既に生成したテーブルを利用する場合に相当する。実施例６に係る処理装置１００は、図１と同様のタイプであり、実施例６に係るブートローダ１１６は、図７と同様のタイプである。ここでは、これまでの実施例との差異を中心に説明する。

実施例１と同様に、ＨＤＤ１０４に記憶された更新用のファームウエアプログラムを不揮発性メモリ１０８に記憶させる際、取得部１３０は、ＨＤＤ１０４や不揮発性メモリ１０８に、既に生成したテーブルが格納されているかを確認する。テーブルが格納されていなければ、取得部１３０および生成部１３２は、実施例１と同様の処理を実行することによって、テーブルを生成する。一方、テーブルが格納されていれば、取得部１３０および生成部１３２は、実施例１での処理を省略し、読出部１３４は、格納されていたテーブルをもとに、スタートアドレスからサイズにわたった連続領域ごとに、ＨＤＤ１０４に分割して記憶された更新用のファームウエアプログラムを読み出す。なお、取得部１３０は、テーブルが格納されていた場合であっても、テーブルの作成日時を確認し、所定の期間よりも前にテーブルが作成されている場合、取得部１３０および生成部１３２は、実施例１と同様の処理を実行してもよい。つまり、テーブルが所定の期間よりも新しい場合にのみ、当該テーブルが利用されればよい。

図１９は、本発明の実施例６に係るブートローダ１１６による書込手順を示すフローチャートである。既存のテーブルがあれば（Ｓ２５０のＹ）、読出部１３４は、テーブルを読み出す（Ｓ２５２）。既存のテーブルがなければ（Ｓ２５０のＮ）、取得部１３０は、スーパーブロックを解析する（Ｓ２５４）。ステップ２５４からステップ２６６は、図１１のステップ１０からステップ２０と同一である。

本発明の実施例によれば、既存のテーブルを読み出すので、テーブル作成のための時間を削減できる。また、テーブル作成のための時間が削減されるので、ファームウエアプログラムの更新時間を短縮できる。また、同じ更新用のファームウエアプログラムを用いて処理を再試行したい場合や、生産時に予め書き込んでおくような場合に、処理期間を短縮できる。

以上、本発明を実施例をもとに説明した。この実施例は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。

実施例１から７の任意の組合せも有効である。本変形例によれば、実施例１から７の任意の組合せによる効果が得られる。

実施例１から７において、ブートローダ１１６は、ファームウエアプログラムを処理の対象にしている。しかしながらこれに限らず例えば、ブートローダ１１６は、ファームウエアプログラム以外のファイルを処理に対象にしてもよい。本変形例によれば、さまざまな種類のファイルの読出処理や書込処理に本発明を適用できる。

実施例１から７において、ＨＤＤ１０４でのファイルシステムとして、ｅｘｔ２ファイルシステムを説明の対象にしている。しかしながらこれに限らず例えば、ＨＤＤ１０４でのファイルシステムとして、ｅｘｔ２以外のファイルシステム、ｅｘｔ３が使用されてもよい。本変形例によれば、さまざまな種類のファイルシステムに対して、本発明を適用できる。

１００ 処理装置、 １０２ プロセッサ、 １０４ ＨＤＤ、 １０６ 揮発性メモリ、 １０８ 不揮発性メモリ、 １１０ 着脱式メモリ、 １１２ チューナ、 １１４ ＣＰＵ、 １１６ ブートローダ、 １１８ ネットワーク、 １２０ サーバ、 １３０ 取得部、 １３２ 生成部、 １３４ 読出部、 １３６ 分割部、 １３８ 書込部。

Claims (11)

1. ファイルを複数のブロックに分割して記憶可能な記憶装置から、前記ファイルを構成する各ブロックのアドレスが示された管理情報を取得する取得部と、
   前記取得部において取得した管理情報から、各ブロックのアドレスを抽出するとともに、アドレスが連続したブロックを連続領域として集約することによって、各連続領域に対する開始アドレスとサイズとが示されたテーブルを生成する生成部と、
   不揮発性メモリに記憶されたデータを読み出す読出部と、
   前記生成部において生成したテーブルをもとに、前記データを、開始アドレスからサイズで決定される終了アドレスまでにわたった連続領域ごとに分割し、分割したデータを、管理情報に示された前記ファイルを構成する各ブロックのアドレスを維持させるように前記記憶装置に書き込む書込部と、
   を備えることを特徴とする処理装置。
2. 前記取得部は、ファイルが複数のブロックに分割して記憶された前記記憶装置から、各ブロックのアドレスが示された管理情報を再取得し、
   前記生成部は、前記取得部において再取得した管理情報から、各ブロックのアドレスを抽出するとともに、アドレスが連続したブロックを連続領域として再集約することによって、各連続領域に対する開始アドレスとサイズとが示されたテーブルを再生成し、
   前記読出部は、前記生成部において再生成したテーブルをもとに、開始アドレスからサイズで決定される終了アドレスまでにわたった連続領域ごとに、前記記憶装置に分割して記憶された前記ファイルを構成する各ブロックのデータを読み出し、
   前記書込部は、前記読出部において読み出した前記各ブロックのデータを前記不揮発性メモリに書き込むことを特徴とする請求項１に記載の処理装置。
3. 前記書込部は、分割したデータを前記記憶装置に書き込む際に、前記記憶装置に記憶されたファイル情報のうち、属性、ファイル名、更新日時の少なくともひとつを更新することを特徴とする請求項１に記載の処理装置。
4. 第１のファームウエアプログラムが複数のブロックに分割して記憶された記憶装置から、各ブロックのアドレスが示された管理情報を取得する取得部と、
   前記取得部において取得した管理情報から、各ブロックのアドレスを抽出するとともに、アドレスが連続したブロックを連続領域として集約することによって、各連続領域に対する開始アドレスとサイズとが示されたテーブルを生成する生成部と、
   前記生成部において生成したテーブルをもとに、開始アドレスからサイズで決定される終了アドレスまでにわたった連続領域ごとに、前記記憶装置に分割して記憶された第１のファームウエアプログラムを読み出す読出部と、
   前記読出部において読み出した第１のファームウエアプログラムによって、不揮発性メモリに記憶された第２のファームウエアプログラムを更新する書込部と、
   を備えることを特徴とする処理装置。
5. 前記読出部は、第１のファームウエアプログラムの一部を読み出し対象とする場合、前記生成部において生成したテーブルをもとに、読み出し対象に対応したブロックだけ読み出すことを特徴とする請求項４に記載の処理装置。
6. 前記読出部は、連続領域を順番につなげていくことによって仮想のアドレスを作成するとともに、読み出し対象の一部のデータの始端と終端が、どの連続領域の仮想アドレス内に存在するかを検出してから、開始アドレスとサイズを調整することを特徴とする請求項５に記載の処理装置。
7. 前記生成部は、既に生成したテーブルを再利用することによって、テーブルの生成を省略することを特徴とする請求項１から６のいずれかに記載の処理装置。
8. ファイルを複数のブロックに分割して記憶可能な記憶装置から、前記ファイルを構成する各ブロックのアドレスが示された管理情報を取得するステップと、
   取得した管理情報から、各ブロックのアドレスを抽出するとともに、アドレスが連続したブロックを連続領域として集約することによって、各連続領域に対する開始アドレスとサイズとが示されたテーブルを生成するステップと、
   不揮発性メモリに記憶されたデータを読み出すステップと、
   生成したテーブルをもとに、前記データを、開始アドレスからサイズで決定される終了アドレスまでにわたった連続領域ごとに分割し、分割したデータを、管理情報に示された前記ファイルを構成する各ブロックのアドレスを維持させるように前記記憶装置に書き込むステップと、
   を備えることを特徴とする書込方法。
9. 第１のファームウエアプログラムが複数のブロックに分割して記憶された記憶装置から、各ブロックのアドレスが示された管理情報を取得するステップと、
   取得した管理情報から、各ブロックのアドレスを抽出するとともに、アドレスが連続したブロックを連続領域として集約することによって、各連続領域に対する開始アドレスとサイズとが示されたテーブルを生成するステップと、
   生成したテーブルをもとに、開始アドレスからサイズで決定される終了アドレスまでにわたった連続領域ごとに、前記記憶装置に分割して記憶された第１のファームウエアプログラムを読み出すステップと、
   読み出した第１のファームウエアプログラムによって、不揮発性メモリに記憶された第２のファームウエアプログラムを更新するステップと、
   を備えることを特徴とする書込方法。
10. ファイルを複数のブロックに分割して記憶可能な記憶装置から、前記ファイルを構成する各ブロックのアドレスが示された管理情報を取得するステップと、
    取得した管理情報から、各ブロックのアドレスを抽出するとともに、アドレスが連続したブロックを連続領域として集約することによって、各連続領域に対する開始アドレスとサイズとが示されたテーブルを生成するステップと、
    不揮発性メモリに記憶されたデータを読み出すステップと、
    生成したテーブルをもとに、前記データを、開始アドレスからサイズで決定される終了アドレスまでにわたった連続領域ごとに分割し、分割したデータを、管理情報に示された前記ファイルを構成する各ブロックのアドレスを維持させるように前記記憶装置に書き込むステップと、
    をコンピュータに実行させるためのプログラム。
11. 第１のファームウエアプログラムが複数のブロックに分割して記憶された記憶装置から、各ブロックのアドレスが示された管理情報を取得するステップと、
    取得した管理情報から、各ブロックのアドレスを抽出するとともに、アドレスが連続したブロックを連続領域として集約することによって、各連続領域に対する開始アドレスとサイズとが示されたテーブルを生成するステップと、
    生成したテーブルをもとに、開始アドレスからサイズで決定される終了アドレスまでにわたった連続領域ごとに、前記記憶装置に分割して記憶された第１のファームウエアプログラムを読み出すステップと、
    読み出した第１のファームウエアプログラムによって、不揮発性メモリに記憶された第２のファームウエアプログラムを更新するステップと、
    をコンピュータに実行させるためのプログラム。

Images