(58)【調査した分野】(Int.Cl.,DB名)
前記書込部は、分割したデータを前記記憶装置に書き込む際に、前記記憶装置に記憶されたファイル情報のうち、属性、ファイル名、更新日時の少なくともひとつを更新することを特徴とする請求項1に記載の処理装置。
前記読出部は、第1のファームウエアプログラムの一部を読み出し対象とする場合、前記生成部において生成したテーブルをもとに、読み出し対象に対応したブロックだけ読み出すことを特徴とする請求項4に記載の処理装置。
前記読出部は、連続領域を順番につなげていくことによって仮想のアドレスを作成するとともに、読み出し対象の一部のデータの始端と終端が、どの連続領域の仮想アドレス内に存在するかを検出してから、開始アドレスとサイズを調整することを特徴とする請求項5に記載の処理装置。
【発明の概要】
【発明が解決しようとする課題】
【0004】
ファームウエアもHDDに記憶されうる。例えば、チューナやネットワークにてダウンロードしたファームウエアや、着脱可能な記憶媒体からコピーしたファームウエアが、一時的にHDDに格納される。ここで、HDDに記憶されたファームウエアが、FLASH ROMなどの不揮発性メモリに書き込まれることによって、ファームウエアが更新される。HDDへのファームウエアの格納、不揮発性メモリへのファームウエアの書込は、アプリケーションプログラムでも可能である。しかしながら、不揮発性メモリへの書き込みに関しては、処理途中の停電や電源引き抜き等が発生すると、次回、アプリケーションを起動できなくなってしまうので、復帰処理も含めると、ブートローダが行うことが望ましい。
【0005】
一方、アプリケーションプログラムがファイルシステム上でファームウエアを格納したとしても、ファイルシステムに対応しないブートローダは、ブロックアドレスを指定して、ファームウエアを直接読み出さなければならない。具体的に説明すると、ブートローダは、ファイルシステム情報を解析する。ext2の場合、ファイルシステム情報は、スーパーブロック、ファイルディスクリプタ等に相当する。これにつづいて、ブートローダは、ディレクトリエントリをサーチしながら、ファームウエアの先頭アドレスを抽出し、その後、必要なファイルの中身、もしくはその一部を読み出す。
【0006】
CD−ROM等で使用されるISO9660ファイルシステムでは、ファイルの先頭アドレスさえ抽出できれば、ファイルの中身のブロックアドレスが連続しているので、適当に読み出し単位を区切って読み出せばよい。しかしながら、ext2の場合、ファイルの中身がブロックアドレスが連続しておらず、データの間に不定期にiノードが含まれている。そのため、ファイルシステムを使用しないブートローダは、1ブロックごとに、iノードによって示されるアドレスを抽出することによって、ファイルを読み出す。iノードを読む度に、シークアクセスのオーバーロードが発生し、処理に時間がかかってしまう。このような課題は、読み出し時だけでなく、書き込み時にも同様に存在する。
【0007】
旧バージョンのファームウエア、あるいはその一部をHDDに記憶させたい場合、ファイルシステムの規則にしたがって作成されたファイルが更新されると、作成されるファイルのブロックアドレスは、毎回変わってしまう。そのため、読み書きの対象となるブロックアドレスが確定せず、結局、ブートローダにファイルシステム相当の処理を組み込むことが必要とされる。その結果、ブートローダのコード量が増大してしまう。これは、リソースの限られた組み込み機器にとって、好ましくない。これの回避策として、ファイルシステムを使用せずに運用するという方法もあるが、逆に、アプリケーションプログラムからファイルを読み書きできなくなるだけでなく、他のファイルを記憶できなくなる。
【0008】
本発明はこうした状況に鑑みてなされたものであり、その目的は、ブートローダによるファイルの読み書きの処理遅延を短縮する技術を提供することである。
【課題を解決するための手段】
【0009】
上記課題を解決するために、本発明のある態様の処理装置は、ファイルを複数のブロックに分割して記憶可能な記憶装置から、ファイルを構成する各ブロックのアドレスが示された管理情報を取得する取得部と、取得部において取得した管理情報から、各ブロックのアドレスを抽出するとともに、
アドレスが抜けるまでアドレスが連続したブロックを連続領域として集約することによって、各連続領域に対する開始アドレスとサイズとが示されたテーブルを生成する生成部と、不揮発性メモリに記憶されたデータを読み出す読出部と、生成部において生成したテーブルをもとに、データを、開始アドレスからサイズで決定される終了アドレスまでにわたった連続領域ごとに分割し、分割したデータを、管理情報に示されたファイルを構成する各ブロックのアドレスを維持させるように記憶装置に書き込む書込部と、を備える。
【0010】
この態様によると、記憶装置から、連続領域に対応した開始アドレスとサイズが示されたテーブルを作成し、テーブルにしたがって、記憶装置にファイルを書き込むので、書込時間を短縮できる。
【0011】
取得部は、ファイルが複数のブロックに分割して記憶された記憶装置から、各ブロックのアドレスが示された管理情報を再取得し、生成部は、取得部において再取得した管理情報から、各ブロックのアドレスを抽出するとともに、
アドレスが抜けるまでアドレスが連続したブロックを連続領域として再集約することによって、各連続領域に対する開始アドレスとサイズとが示されたテーブルを再生成し、読出部は、生成部において再生成したテーブルをもとに、開始アドレスからサイズで決定される終了アドレスまでにわたった連続領域ごとに、記憶装置に分割して記憶されたファイルを構成する各ブロックのデータを読み出し、書込部は、読出部において読み出した各ブロックのデータを不揮発性メモリに書き込んでもよい。この場合、記憶装置に記憶されたファイル内の連続領域に対応した開始アドレスとサイズが示されたテーブルを再作成し、テーブルにしたがって読み出し処理を実行するので、更新時間を短縮できる。
【0012】
書込部は、分割したデータを記憶装置に書き込む際に、記憶装置に記憶されたファイル情報のうち、属性、ファイル名、更新日時の少なくともひとつを更新してもよい。この場合、属性、ファイル名、更新日時の少なくともひとつを更新するので、更新完了した証拠を残すことができる。
【0013】
本発明の別の態様もまた、処理装置である。この装置は、第1のファームウエアプログラムが複数のブロックに分割して記憶された記憶装置から、各ブロックのアドレスが示された管理情報を取得する取得部と、取得部において取得した管理情報から、各ブロックのアドレスを抽出するとともに、
アドレスが抜けるまでアドレスが連続したブロックを連続領域として集約することによって、各連続領域に対する開始アドレスとサイズとが示されたテーブルを生成する生成部と、生成部において生成したテーブルをもとに、開始アドレスからサイズで決定される終了アドレスまでにわたった連続領域ごとに、記憶装置に分割して記憶された第1のファームウエアプログラムを読み出す読出部と、読出部において読み出した第1のファームウエアプログラムによって、不揮発性メモリに記憶された第2のファームウエアプログラムを更新する書込部と、を備える。
【0014】
この態様によると、記憶装置に記憶された第1のファームウエアプログラム内の連続領域に対応した開始アドレスとサイズが示されたテーブルを作成し、テーブルにしたがって読み出し処理を実行するので、更新時間を短縮できる。
【0015】
読出部は、第1のファームウエアプログラムの一部を読み出し対象とする場合、生成部において生成したテーブルをもとに、読み出し対象に対応したブロックだけ読み出す。この場合、連続領域のうち、読み出し対象に対応したブロックだけを読み出すので、第1のファームウエアプログラムの一部を読み出し対象とする場合にも対応できる。
【0016】
生成部は、既に生成したテーブルを再利用することによって、テーブルの生成を省略してもよい。この場合、既に生成したテーブルを再利用するので、処理期間を短縮できる。
【0017】
本発明のさらに別の態様は、書込方法である。この方法は、ファイルを複数のブロックに分割して記憶可能な記憶装置から、ファイルを構成する各ブロックのアドレスが示された管理情報を取得するステップと、取得した管理情報から、各ブロックのアドレスを抽出するとともに、
アドレスが抜けるまでアドレスが連続したブロックを連続領域として集約することによって、各連続領域に対する開始アドレスとサイズとが示されたテーブルを生成するステップと、不揮発性メモリに記憶されたデータを読み出すステップと、生成したテーブルをもとに、データを、開始アドレスからサイズで決定される終了アドレスまでにわたった連続領域ごとに分割し、分割したデータを、管理情報に示されたファイルを構成する各ブロックのアドレスを維持させるように記憶装置に書き込むステップと、を備える。
【0018】
本発明のさらに別の態様もまた、書込方法である。この方法は、第1のファームウエアプログラムが複数のブロックに分割して記憶された記憶装置から、各ブロックのアドレスが示された管理情報を取得するステップと、取得した管理情報から、各ブロックのアドレスを抽出するとともに、
アドレスが抜けるまでアドレスが連続したブロックを連続領域として集約することによって、各連続領域に対する開始アドレスとサイズとが示されたテーブルを生成するステップと、生成したテーブルをもとに、開始アドレスからサイズで決定される終了アドレスまでにわたった連続領域ごとに、記憶装置に分割して記憶された第1のファームウエアプログラムを読み出すステップと、読み出した第1のファームウエアプログラムによって、不揮発性メモリに記憶された第2のファームウエアプログラムを更新するステップと、を備える。
【0019】
なお、以上の構成要素の任意の組合せ、本発明の表現を方法、装置、システム、記録媒体、コンピュータプログラムなどの間で変換したものもまた、本発明の態様として有効である。
【発明の効果】
【0020】
本発明によれば、ブートローダによるファイルの読み書きの処理遅延を短縮できる。
【発明を実施するための形態】
【0022】
(実施例1)
本発明を具体的に説明する前に、まず概要を述べる。本発明の実施例は、HDD(Hard Disk Drive)に記憶されたファームウエアプログラムによって、不揮発性メモリに記憶されたファームウエアプログラムを更新するためのブートローダに関する。ここでは、一例として、HDDに使用されるファイルシステムが、ext2であるとする。ext2において、ファームウエアプログラムは、複数のブロックに分割されて記憶される。なお、複数のブロックが連続しているとは限らない。詳細は後述するが、HDDからのファームウエアプログラムの読出し期間を短くするためには、シークの繰り返し回数を少なくし、連続したブロックを一度に読み出すことが有効である。
【0023】
一方、ブートローダは、HDDに記憶されたファームウエアプログラムのブロックアドレスを予め認識していないので、ブロックアドレスが示されたiノードを取得しなければならない。このiノードは、HDD内において分散して格納されるので、iノードからブロックアドレスを取得しながら、ファームウエアプログラムを読み出す場合、連続したブロックを一度に読み出すことが困難になる。そのため、読出し速度の高速化が困難になる。これに対応するために、実施例に係るブートローダは、次の処理を実行する。
【0024】
ブートローダは、ファームウエアプログラムを読み出す前に、iノードからブロックアドレスを取得し、連続したブロック(以下、「連続領域」という)に関するテーブルを生成する。当該テーブルには、各連続領域のスタートアドレスとサイズとが示されている。ブートローダは、テーブルを参照しながら、連続したブロックを一度に読み出すことによって、HDDからのファームウエアプログラムの読出しを高速化させる。
【0025】
図1は、本発明の実施例1に係る処理装置100の構成を示す。処理装置100は、プロセッサ102、HDD104、揮発性メモリ106、不揮発性メモリ108、着脱式メモリ110、チューナ112を含む。また、プロセッサ102は、CPU(中央処理装置)114、ブートローダ116を含む。さらに、処理装置100は、ネットワーク118を介してサーバ120に接続される。
【0026】
プロセッサ102は、集積回路等にて実現される。プロセッサ102は、CPU114と、ブートローダ116のほか、多種のドライバ、専用処理モジュールを統合している。プロセッサ102は、多様なデバイスやメディアとアクセス可能である。不揮発性メモリ108は、FLASH ROM、EEPROM等であり、CPU114が処理すべきプログラムを格納する。また、不揮発性メモリ108は、ファームウエアプログラムを記憶する。揮発性メモリ106は、SDRAM等で構成された実処理用のメモリである。ブートローダ116がプログラムを不揮発性メモリ108から揮発性メモリ106へ読み込んで起動させることにより、CPU114がプログラムを処理可能になる。なお、ブートローダ116の処理は、段階的に分けることができるので、一部がプログラムに含まれる場合もある。
【0027】
チューナ112は、BS/CS/地上波デジタル/地上波アナログ等を受信可能なモジュールであり、プロセッサ102による制御によって、受信データを出力する。HDD104は、各種のプログラムや、チューナ112によって受信したデータ等を蓄積する。ここで、HDD104は、不揮発性メモリ108に記憶されたファームウエアプログラムよりも新しいバージョンのファームウエアプログラムを記憶する。プロセッサ102には、着脱式メモリ110のドライバが含まれており、着脱式メモリ110に対してデータの読み書きが可能である。また、プロセッサ102は通信用のドライバを有しており、インターネット、イントラネット等のネットワーク118を介して、遠隔地のサーバ120と通信する。
【0028】
不揮発性メモリ108には、一般的に、工場出荷時に、ファームウエアプログラム等のプログラムが書き込まれている。プログラムの内容の修正や性能向上を目的として、出荷後に、ユーザの使用環境において、プログラムの更新がなされる。プログラム更新の一例が、衛星放送を利用したオンエアダウンロードによる更新である。これでは、番組表等と同様に、プログラムの更新データがチューナ112によってダウンロードされ、データを蓄積後、プログラム更新がなされる。同様に遠隔地からダウンロードする方法として、遠隔地のサーバ120から、ネットワーク118を経由してプログラムの更新データがダウンロードされ、データを蓄積後、プログラム更新がなされてもよい。さらに、他の方法として、着脱式メモリ110に記憶されたデータがコピーされ、データを蓄積後、プログラム更新がなされてもよい。
【0029】
本実施例は、プログラム更新として、ファームウエアプログラムの更新を対象とする。ファームウエアプログラムの更新における処理は、更新データを取得して蓄積するための処理(以下、「蓄積処理」という)、蓄積した更新データを読み出して、不揮発性メモリ108に書き込む処理(以下、「書込処理」という)に分類される。前述のごとく、更新データは、HDD104に蓄積される。蓄積処理は、オンエアダウンロードやネットワーク118経由のダウンロードなど、アプリケーションプログラムの動作中になされるので、蓄積処理自体も、アプリケーションプログラムによってなされる。着脱式メモリ110からのデータコピーも、アプリケーションプログラムの動作中であれば、ファイルをコピーするだけですむので、アプリケーションプログラムによる蓄積処理が適している。
【0030】
一方、書込処理は、アプリケーションプログラムでも実現可能ではあるが、アプリケーションプログラムは更新データに含まれる。そのため、書き込み中に停電や、ユーザによる電源引き抜きが発生すると、次回、OS(Operating System)やアプリケーションプログラムが正常に起動しなくなるおそれがある。結果として、書き込みの再試行が不可能となり、2度と復帰しなくなってしまう。そのため、蓄積した更新データを読み出して、不揮発性メモリ108に書き込む処理は、OSやアプリケーションに依存しないブートローダ116によってなされることが望ましい。なお、書込処理をブートローダ116が行う場合、前処理である更新データを取得して蓄積する処理との間には、リブート処理が伴うため、データの蓄積場所は、不揮発性かつ、更新用のソフトウエアプログラムを格納可能な容量が必要になる。そのため、HDD104が、更新用のソフトウエアプログラムの蓄積場所に適している。
【0031】
図2は、HDD104におけるext2ファイルシステムの概要を示す。OSにLinuxを用いる場合、ブロックファイルシステムとしては、ext2が使用されることが多い。ext2は、Fast File Systemをもとに開発されており、UNIX(登録商標)で伝統的に用いられてきた「ブロック管理アルゴリズム」をベースとしている。ext2では、1024、2048、4096bytesのいずれかでブロック単位が構成され、複数のブロックが「ブロックグループ」にまとめて管理される。
図2では、ブロックグループの構造が示される。
図2の左側は、
図1のHDD104内に形成されたパーティションを示し、
図2の中央は、ext2パーティションのレイアウトを示す。
図2の右側は、ブロックグループ内のレイアウトをさらに詳細を示す。ここで、スーパーブロックとは、ファイルシステムに関する管理情報であり、グループディスクリプタとは、グループ内の情報であり、データブロックビットマップとは、データブロックの情報である。また、iノードテーブルは、ファイル/ディレクトリに関する情報を保持するiノードを格納し、データブロックは、実際のデータを保持する。
【0032】
図1のブートローダ116は、スーパーブロックやグループディスクリプタの情報でファイルシステムの情報を得た後、ディレクトリエントリ内をサーチし、目的のファイルに対応したiノードテーブルの情報を得る。iノードテーブルにもとづいて、データブロックのメモリアドレスを求めることによって、実際のファイル内データの読み込みが可能になる。データブロックのサイズは、ほかのブロックと同じ1024、2048、4096bytesのいずれかの値である。データブロックのサイズが2048byteで、ファイルサイズが200Kbytesであるファイルの参照には、100個のデータブロックが必要になる。しかしながら、100個のデータブロックに対して100個のアドレスを保持する場合、情報量が増大してしまうので、ext2では効率的にアドレス範囲を使用するために間接ブロックを作成し、間接ポインタによって参照できるようにしている。
【0033】
図3は、HDD104におけるiノードテーブルとブロックアドレスの概要を示す。iノードがもつデータブロック参照用の配列は15個であり、ext2では、そのうち12個を「直接参照」、残りの3つをそれぞれ「一段間接参照」「二段間接参照」「三段間接参照」用に使用する。これにより、ext2は、複数のデータブロックを必要とする容量の大きいファイルを効率的に扱う。それぞれの参照方法で、表現可能なファイルサイズは、計算上、次のようになる。直接参照の計算式は、「ブロックサイズ×12個」である。ブロックサイズが1024bytes、2048bytes、4096bytesの場合、それぞれファイルサイズは、12Kbytes、24Kbytes、48Kbytesになる。
【0034】
一段間接参照では、間接参照用に「ブロックサイズ÷4」個分使用できる。これは、ブロックポインタの大きさ[byte]に相当する。そのため、ファイルサイズに換算すると、「ブロックサイズ÷4*ブロックサイズ」になり、ブロックサイズが1024bytes、2048bytes、4096bytesの場合、それぞれのファイルサイズは、256Kbytes、1Mbytes、4Mbytesになる。二段間接参照では、ファイルサイズに換算すると、「((ブロックサイズ÷4)
2)×ブロックサイズ」になる。そのため、ブロックサイズが1024bytes、2048bytes、4096bytesの場合、それぞれのファイルサイズは、64Mbytes、512Mbytes、4Gbytesになる。
図1の不揮発性メモリ108に書き込むべき更新用プログラムのファイルサイズが数十〜数百Mbytesである場合、二段間接参照の使用が望ましい。
【0035】
図4は、HDD104におけるブロックアドレス上のファイルとiノードの関係を示す。iノード自体は、HDD104において、まとまった領域に格納されておらず、データブロック内に形成される。そのため、間接参照を使用した場合、元ファイルのデータに連続性がなくなる。これはカーネルが、iノードとそれに対応するデータブロックを読み込む際にディスクヘッドのシークを減らすために、iノードをデータブロックと同じグループ内に割り当てようとするためである。アドレス表現が4bytesの場合、1ブロック中に格納出来るアドレス数は、「ブロックサイズ÷4」となる。つまり、計算上、「ブロックサイズ÷4」に1回は、データの中にiノードを入れないと、全てのアドレスを表現することが出来ない。例えば、2048bytesの場合、512bytesに1回はiノードが埋め込まないと、全てのアドレスを表現することが出来ない。そして、実際には、必ずしも512bytesではなく、不定期に、より少ない間隔でiノードが挿入される。さらに、ファイルの位置と、その中に含まれるiノードの位置は、ファイル生成ごとに更新されるので、特定が困難になる。つまり、
図1のブートローダ116は、ファイルの先頭データが入っているブロックアドレスを抽出したとしても、ブロックを連続して読み出せず、1ブロックごとに参照を行いながら、データのブロックアドレスを読み出さなければならない。
【0036】
図5は、HDD104の構成を示す。同心円状に生成されたトラック150に、データを読み書きする単位として、セクタ152という領域が形成される。スイングアーム144で磁気ヘッド146が、ディスク140上を移動させられて、データへのアクセスがなされる。この操作をシークと呼び,その所要時間をシーク時間と呼ぶ.同じシリンダ148内であればシーク時間がないので、回転待ち時間のみとなるが、シークを伴う場合は、シーク時間を考慮しなければならない。一般的に、HDD104のデータ読み出し時間は「(平均シーク時間+平均回転待ち時間+データ転送時間)×(シークの繰り返し回数)」で計算される。ここで、データの転送時間<<(平均シーク時間+平均回転待ち時間)の関係が成立される。そのため、「シークの繰り返し回数」が少ないほど、全体のデータ読み出し時間は短くなる。また、ひとつのトラック150を越えるサイズのファイルを読み出す場合に、連続したアドレスを一度に読み込む方が、ロングシークではなく、1トラックジャンプでアクセスできるので、データ読み出し時間が短くなる。
【0037】
図6は、HDD104の読み出し単位ブロック数と読み出し時間の関係を示す。これは、アクセス単位を変更しながら、128Mbytesのデータの読み出し時間を計測した結果である。1ブロック単位の読み出しに対して、読み出し単位ブロック数を増やしていくにしたがって、読み出し時間が大きく減少し、128Mbytes付近で飽和している。
【0038】
図7は、ブートローダ116の構成を示す。ブートローダ116は、取得部130、生成部132、読出部134、分割部136、書込部138を含む。取得部130は、
図1のHDD104におけるext2ファイルシステム上に構成されているスーパーブロックを解析し、ブロックサイズなどの必要な情報を取得する。取得部130は、グループディスクリプタを解析し、iノードテーブルIDなど必要な情報を取得する。取得部130は、ディレクトリエントリをサーチし、アップデートファイルのiノード情報を取得する。
【0039】
生成部132は、更新用のファームウエアプログラムが複数のブロックに分割して記憶されたHDD104から、各ブロックのアドレスが示された管理情報を取得する。生成部132は、取得した管理情報、つまりiノードテーブルの情報と間接参照を用いてファイル内の各ブロックに対応したブロックアドレスを抽出する。生成部132は、ブロックアドレスが連続したブロックを連続領域として集約する。
図8は、生成部132において生成される連続領域の概要を示す。ここで、ブロックアドレスと、連続領域のスタートアドレスとサイズを示すテーブルの関係について補足する。
図8は、ファイル内の全ブロックを配列として表現し、それぞれのブロックアドレスとの対応を示したものである。直接参照であるBlock[0]からBlock[11]までは、ブロックアドレスも連続しているが、Block[12]からは、ブロックアドレスがひとつずれている。これは、iノードの間接参照に使用されているため、0x00001C0Cが抜けているためである。
図7に戻る。
【0040】
また、生成部132は、各連続領域に対するスタートアドレスとサイズとが示されたテーブルを生成する。テーブルは、
図1の揮発性メモリ106上に配列として構成されてもよいし、HDD104や不揮発性メモリ108に格納されてもよい。
図9は、生成部132において生成されるテーブルを示す。最初の連続領域は、
図8のBlock[0]からBlock[11]の範囲となり、対応するスタートアドレスとサイズは、
図9の最初の行に示す値になる。第2の連続領域以降も同様であり、結果として、
図9のようなテーブルが生成される。
図9のテーブルのサイズは、
図8のテーブルのサイズよりも格段に小さい。例えば、ファームウエアプログラムのファイルサイズが数十〜数百Mbytesで、ブロックサイズが2048bytesの場合、2段間接参照で実現でき、概算で1/(2048/4)=1/512のテーブルサイズとなる。そのため、
図8のテーブルを保持する場合よりも、テーブルを保持するためのリソースが大幅に削減される。
図7に戻る。
【0041】
読出部134は、生成部132において生成したテーブルをもとに、スタートアドレスからサイズにわたった連続領域ごとに、HDD104に分割して記憶された更新用のファームウエアプログラムを読み出す。つまり、読出部134は、連続領域に含まれた複数のブロックをまとめて読み出す。読出部134は、読み出したファームウエアプログラムを揮発性メモリ106に一時的に記憶する。このとき、更新用のファームウエアプログラム内の一部を切り出す場合、切り出す一部の始端と終端が連続領域の区切りになっているとは限らない。その際、読出部134は、始端と終端がどの連続領域に含まれるかを予め検出し、スタートアドレスとサイズを調整する。
【0042】
例えば、連続領域の途中のブロックが始端である場合、始端に対応したブロックまで、スタートアドレスが後方にずらされる。また、終端についても同様である。つまり、読出部134は、更新用のファームウエアプログラムの一部を読み出し対象とする場合、生成部132において生成したテーブルをもとに、読み出し対象に対応したブロックだけ読み出す。書込部138は、揮発性メモリ106から更新用のファームウエアプログラムを読み出して、不揮発性メモリ108に書き込む。つまり、書込部138は、読出部134において読み出した更新用のファームウエアプログラムによって、不揮発性メモリ108に記憶されたこれまでのファームウエアプログラムを更新する。なお、分割部136は、実施例1において、動作しない。
【0043】
ファイル内の一部のデータに対して、読み書きする場合、
図9のテーブルにおける連続領域の区切りが始端と終端になっているとは限らない。よって、読み書きを開始する前に、予め、始端と終端がどの連続領域に含まれるかを検出し、各々のスタートアドレスとサイズを調整することで対応する。
図10は、読出部134における始端と終端によるスタートアドレスとサイズの調整の概念図である。始端と終端における、スタートアドレスとサイズの調整を行うためには、まず、
図10の右側に示すように、連続領域を順番につなげていき、仮想のアドレスを作成する(実際には、間にi−nodeが入るので、実アドレスとは異なる)。その過程において、読み出し対象のデータの(ファイル先頭基準における)先頭位置を示すstart、および終端位置を示すendが、各連続領域の仮想アドレス内に存在するかどうかを検出する。図に示すように、startとendを実線で囲んだ領域が読み出したいデータである。この場合のstart位置は、Ext[3]に含まれるので、Ext[3]につき、スタートアドレスを後ろにずらし、かつサイズを小さくすることで、補正が可能となる。同様に、end位置については、Ext[112]に含まれるので、Ext[112]につき、サイズを小さくすることで、補正が可能となる。
【0044】
この構成は、ハードウエア的には、任意のコンピュータのCPU、メモリ、その他のLSIで実現でき、ソフトウエア的にはメモリにロードされたプログラムなどによって実現されるが、ここではそれらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックがハードウエアのみ、ソフトウエアのみ、またはそれらの組合せによっていろいろな形で実現できることは、当業者には理解されるところである。
【0045】
以上の構成によるブートローダ116の動作を説明する。
図11は、ブートローダ116による書込手順を示すフローチャートである。取得部130は、ext2ファイルシステム上に構成されているスーパーブロックの解析を行い(S10)、ブロックサイズなどの必要な情報を取得する。取得部130は、グループディスクリプタの解析を行い(S12)、iノードテーブルIDなど必要な情報を取得する。取得部130は、ディレクトリエントリをサーチし、アップデートファイルのiノード情報を取得する(S14)。
【0046】
生成部132は、iノードテーブルの情報と間接参照を用いてファイル内の各ブロックに対応したブロックアドレスを抽出し、連続領域のスタートアドレスとサイズを示すテーブルを作成する(S16)。読出部134は、連続領域ごとに更新用ファームウエアをHDD104より読み出して、揮発性メモリ106に一時格納する(S18)。書込部138は、揮発性メモリ106から更新用ファームウエアを読み出して不揮発性メモリ108へ書き込む(S20)。
【0047】
図12は、生成部132におけるテーブルの作成手順を示すフローチャートである。生成部132は、ファイルの先頭に位置する先頭ブロックアドレスを抽出する(S40)。生成部132は、連続領域のスタートアドレスに、抽出した先頭ブロックアドレスの値を入れる(S42)。生成部132は、パラメータ(連続領域番号、連続領域サイズ、ブロック数カウンタ)を初期化する(S44)。ブロック数カウンタmがブロックサイズを超えていなければ(S46のY)、生成部132は、ブロックアドレスを抽出する(S48)。
【0048】
生成部132は、ブロックアドレスが、ひとつ前のデータのブロックアドレスと連続しているかを確認し、連続している場合には(S50のY)、サイズのみインクリメントする(S54)。連続していない場合には(S50のN)、生成部132は、連続領域番号をインクリメントするとともに、スタートアドレスを現在対象としているブロックアドレスで更新し、サイズを初期化(1)する(S52)。生成部132は、ブロック数カウンタをインクリメントした(S56)後にステップ46に戻る。ブロック数カウンタmがブロックサイズを超えれば(S46のN)、処理は終了する。
【0049】
図13は、生成部132におけるブロックアドレスの抽出手順を示すフローチャートである。これは、
図12のステップ40、ステップ48でのブロックアドレスの抽出に相当する。
図11のステップ14にて得られたiノード情報により、
図3に示したiノードテーブルの中から、対象のiノードの抽出が可能であるが、説明を明瞭にするため、この中の参照情報を抜き出したものをi_node[i] 0<i<15とする(S70)。i<12であれば(S72のY)、生成部132は、直接参照を行い、ブロックアドレスを抽出する(S74)。i<12でなく(S72のN)、i=12であれば(S76のY)、生成部132は、一段間接参照行ってブロックアドレスを抽出する(S78)。i=12でなく(S76のN)、i=13であれば(S80のY)、生成部132は、二段間接参照を行い、ブロックアドレスを抽出する(S82)。i=13でなければ(S80のN)、つまりi=14であれば、生成部132は、三段間接参照を行い、ブロックアドレスを抽出する(S84)。
【0050】
本発明の実施例によれば、HDDに格納された更新用のファームウエアプログラム内の連続領域に対応したスタートアドレスとサイズとが示されたテーブルを作成し、テーブルにしたがって読み出し処理を実行するので、ファームウエアプログラムの更新時間を短縮できる。また、テーブルを作成するので、ファイルシステムをもたないブートローダが、不揮発性メモリに格納されたファームウエアプログラムを更新する場合であっても、更新時間を短縮できる。また、HDDからの読み出しサイズは、「ブロックサイズ÷4」に近くなるので、読出しを高速にできる。また、ファイルシステム上でファイルの再配置等が行われた場合でも、柔軟に追従するので、性能への影響を低減できる。また、連続領域のテーブルの情報量は、ブロックアドレスについてのテーブルの情報量よりも小さいので、処理の効率を向上できる。
【0051】
(実施例2)
本発明の実施例2は、実施例1と同様に、ファームウエアプログラムを書き込むためのブートローダに関する。一方、実施例2は、実施例1と異なり、不揮発性メモリに記憶されたファームウエアプログラムをHDDに一時格納する場合に相当する。ここで、HDDへの一時格納は、ファームウエアプログラムのバックアップを目的としてなされる。つまり、実施例2と実施例1では、ファームウエアプログラムを読み出すべき記憶媒体と、ファームウエアプログラムを書き込むべき記憶媒体とが反対になる。実施例2に係る処理装置100は、
図1と同様のタイプであり、実施例2に係るブートローダ116は、
図7と同様のタイプである。ここでは、実施例1との差異を中心に説明する。
【0052】
なお、HDD104には、バックアップ用のファームウエアプログラム、もしくはバックすべきファームウエアプログラムと同サイズのファイルが、ファイルシステム上において、アプリケーションプログラム等によって格納されている。取得部130は、
図1のHDD104に対して、スーパーブロックおよびグループディスクリプタを解析する。さらに、取得部130は、ディレクトリエントリをサーチし、HDD104に既に記憶しているファイルのiノード情報を取得する。
【0053】
生成部132は、バックアップ用のファームウエア等のファイルを複数のブロックに分割して記憶可能なHDD104から、各ブロックのアドレスが示された管理情報を取得する。生成部132は、iノードテーブルの情報と間接参照を用いてファイル内の各ブロックに対応したブロックアドレスを抽出する。生成部132は、ブロックアドレスが連続したブロックを連続領域として集約する。生成部132は、各連続領域に対するスタートアドレスとサイズとが示されたテーブルを生成する。読出部134は、不揮発性メモリ108に記憶されたファームウエアプログラムを読み出し、揮発性メモリ106に一時格納する。読み出したファームウエアプログラムが、これからバックアップすべきファームウエアプログラムである。
【0054】
分割部136は、揮発性メモリ106に記憶したファームウエアプログラムを分割する。また、分割部136は、生成部132において集約した連続領域に適合するように、分割した複数のブロックを集約する。このような処理によって、生成部132において生成した各連続領域に対応するように、ファームウエアプログラムが複数に分割される。書込部138は、生成部132において生成したテーブルをもとに、スタートアドレスからサイズにわたった連続領域ごとに、分割部136において分割したファームウエアプログラムをHDD104に書き込む。つまり、連続領域のアドレスを変更させないように、複数に分割されたファームウエアプログラムがHDD104に書き込まれる。その結果、iノードテーブルのような管理情報に示されたブロックアドレスも変化されない。HDD104にファームウエアプログラムを書き込むことが、ファームウエアプログラムをバックアップすることに相当する。
【0055】
図14は、本発明の実施例2に係るブートローダ116による書込手順を示すフローチャートである。取得部130は、ext2ファイルシステム上に構成されているスーパーブロックの解析を行い(S100)、ブロックサイズなどの必要な情報を取得する。取得部130は、グループディスクリプタの解析を行い(S102)、iノードテーブルIDなど必要な情報を取得する。取得部130は、ディレクトリエントリをサーチし、バックアップ用ファイルのiノード情報を取得する(S104)。
【0056】
生成部132は、iノードテーブルの情報と間接参照を用いてファイル内の各ブロックに対応したブロックアドレスを抽出し、連続領域のスタートアドレスとサイズを示すテーブルを作成する(S106)。読出部134は、不揮発性メモリ108からファームウエアを揮発性メモリ106へ読み出す(S108)。書込部138は、揮発性メモリ106からバックアップ用ファームウエアを読み出して、連続領域ごとに、HDD104でのバックアップファイルに書き込む(S110)。
【0057】
本発明の実施例によれば、予めアプリケーションプログラム等によって生成した同サイズのファイルに対して、連続領域に対応したスタートアドレスとサイズが示されたテーブルを作成し、テーブルにしたがって書き込み処理を実行するので、バックアップ時間を短縮できる。また、テーブルにしたがって書き込み処理を実行するので、HDD内にバックアップ用データを記憶する際にも、書込処理を高速にできる。また、テーブルにしたがって書き込み処理を実行するので、ファイルシステムを用いたアプリケーションプログラムの処理と共存できる。また、ファイルシステムをもたないブートローダによるファイルの書込みは、困難であるが、先に配置した同サイズのファイルのブロックアドレスを利用して書込みを行うので、ファイルシステム上のアプリケーションプログラムの処理との共存を実現できる。
【0058】
なお、上記説明では、分割部136と書込部138とが分離している場合について説明したが、実際の処理においては、揮発性メモリ106とHDD104の間でデータ転送(コピー)するAPI(Application Program Interface)、もしくは、関数を用意して、指定するアドレスをずらしていくことにより、実現してもよいことは、勿論である。
【0059】
(実施例3)
本発明の実施例3は、実施例2の動作につづいて、実施例1の動作を実行する場合に相当する。つまり、実施例3は、実施例2の動作によってHDDに記憶されたバックアップファイルを利用し、不揮発性メモリのファームウエアプログラムを更新する場合に相当する。このようなファームウエアプログラムの更新は、ファームウエアプログラムのリカバリーともいえる。実施例3に係る処理装置100は、
図1と同様のタイプであり、実施例3に係るブートローダ116は、
図7と同様のタイプである。ここでは、これまでの実施例との差異を中心に説明する。
【0060】
HDD104には、バックアップ用のファームウエアプログラムが、ファイルシステム上において、実施例2での処理によって格納されている。取得部130は、
図1のHDD104におけるext2ファイルシステム上に構成されているスーパーブロックおよびグループディスクリプタを解析する。取得部130は、ディレクトリエントリをサーチし、バックアップ用ファイルのiノード情報を再取得する。つまり、取得部130は、バックアップ用のファームウエアプログラムが複数のブロックに分割して記憶されたHDD104から、各ブロックのアドレスが示された管理情報を再取得する。
【0061】
生成部132は、取得部130において取得した管理情報、つまりiノードテーブルの情報と間接参照を用いてバックアップ用のファームウエアプログラム内の各ブロックに対応したブロックアドレスを抽出する。生成部132は、ブロックアドレスが連続したブロックを連続領域として集約する。生成部132は、各連続領域に対するスタートアドレスとサイズとが示されたテーブルを再生成する。読出部134は、生成部132において再生成したテーブルをもとに、スタートアドレスからサイズにわたった連続領域ごとに、HDD104に分割して記憶されたバックアップ用のファームウエアプログラムを読み出す。読出部134は、読み出したファームウエアプログラムを揮発性メモリ106に一時的に記憶する。
【0062】
書込部138は、揮発性メモリ106からバックアップ用のファームウエアプログラムを読み出して、不揮発性メモリ108に書き込む。つまり、書込部138は、読出部134において読み出したバックアップ用のファームウエアプログラムによって、不揮発性メモリ108に記憶されたこれまでのファームウエアプログラムをリカバリーする。なお、分割部136は、実施例3において、動作しない。
【0063】
図15は、本発明の実施例3に係るブートローダ116による書込手順を示すフローチャートである。取得部130は、ext2ファイルシステム上に構成されているスーパーブロックの解析を行い(S130)、ブロックサイズなどの必要な情報を取得する。取得部130は、グループディスクリプタの解析を行い(S132)、iノードテーブルIDなど必要な情報を取得する。取得部130は、ディレクトリエントリをサーチし、アップデートファイルのiノード情報を取得する(S134)。
【0064】
生成部132は、iノードテーブルの情報と間接参照を用いてファイル内の各ブロックに対応したブロックアドレスを抽出し、連続領域のスタートアドレスとサイズを示すテーブルを作成する(S136)。読出部134は、連続領域ごとにバックアップ用ファームウエアをHDD104より読み出して、揮発性メモリ106に一時格納する(S138)。書込部138は、揮発性メモリ106からバックアップ用ファームウエアを読み出して不揮発性メモリ108へ書き込む(S140)。
【0065】
本発明の実施例によれば、HDDに格納された更新用のファームウエアプログラム内の連続領域に対応したスタートアドレスとサイズとが示されたテーブルを作成し、テーブルにしたがって読み出し処理を実行するので、ファームウエアプログラムのリカバリー時間を短縮できる。また、テーブルを作成するので、ファイルシステムをもたないブートローダが、不揮発性メモリに格納されたファームウエアプログラムを更新する場合であっても、リカバリー時間を短縮できる。
【0066】
(実施例4)
本発明の実施例4は、実施例2と同様に、不揮発性メモリに記憶されたファームウエアプログラムをHDDに一時格納する場合に相当する。実施例4では、ファームウエアプログラムをHDDに格納する際に、ファイル情報も更新される。実施例4に係る処理装置100は、
図1と同様のタイプであり、実施例4に係るブートローダ116は、
図7と同様のタイプである。ここでは、これまでの実施例との差異を中心に説明する。
【0067】
書込部138は、実施例2と同様に、生成部132において生成したテーブルをもとに、スタートアドレスからサイズにわたった連続領域ごとに、分割部136において分割したファームウエアプログラムをHDD104に書き込む。その際、書込部138は、HDD104に書き込むべきファームウエアプログラムについてのファイル情報のうち、属性、ファイル名、更新日時の少なくともひとつを更新する。
【0068】
図16は、本発明の実施例4に係るブートローダ116による書込手順を示すフローチャートである。
図16のステップ160からステップ170は、
図14のステップ100からステップ110と同一である。書込部138は、ファイル情報のうち、属性、ファイル名、更新日時の少なくともひとつを更新する(S172)。
【0069】
本発明の実施例によれば、ファイル情報のうち、属性、ファイル名、更新日時の少なくともひとつを更新するので、更新完了した証拠を残すことができる。また、ファイル情報のうち、属性、ファイル名、更新日時の少なくともひとつを更新することによって、ファイルシステム上のデータを更新するので、アプリケーションプログラムからも更新を確認できる。
【0070】
(実施例5)
本発明の実施例5は、実施例2において使用したテーブルと、実施例3において使用したテーブルを共通化する場合に相当する。つまり、実施例5は、不揮発性メモリに記憶したファームウエアプログラムをHDDにバックアップファイルとして一時格納させる場合と、HDDに一時格納したバックアップファイルを利用することによって、不揮発性メモリに記憶したファームウエアプログラムを更新する場合とにおいてテーブルを共通化することに関する。このような処理によって、テーブル作成のための時間を削減することが可能になる。実施例5に係る処理装置100は、
図1と同様のタイプであり、実施例5に係るブートローダ116は、
図7と同様のタイプである。ここでは、これまでの実施例との差異を中心に説明する。
【0071】
実施例2と同様に、不揮発性メモリ108に記憶されたファームウエアプログラムをHDD104に記憶させる際、取得部130は、HDD104や不揮発性メモリ108に、既に生成したテーブルが格納されているかを確認する。テーブルが格納されていなければ、取得部130および生成部132は、実施例2と同様の処理を実行することによって、テーブルを生成する。一方、テーブルが格納されていれば、取得部130および生成部132は、実施例2での処理を省略し、読出部134は、不揮発性メモリ108に記憶されたファームウエアプログラムを読み出し、揮発性メモリ106に一時格納する。
【0072】
実施例3と同様に、HDD104に記憶されたバックアップ用のファームウエアプログラムを不揮発性メモリ108に記憶させる際も、取得部130は、HDD104や不揮発性メモリ108に、既に生成したテーブルが格納されているかを確認する。ここで、テーブルは、過去において、不揮発性メモリ108に記憶されたファームウエアプログラムをHDD104に記憶させる際、あるいはHDD104に記憶されたファームウエアプログラムを不揮発性メモリ108に記憶させる際に生成されいればよい。テーブルが格納されていなければ、取得部130および生成部132は、実施例3と同様の処理を実行することによって、テーブルを生成する。一方、テーブルが格納されていれば、取得部130および生成部132は、実施例3での処理を省略し、読出部134は、格納されていたテーブルをもとに、スタートアドレスからサイズにわたった連続領域ごとに、HDD104に分割して記憶されたバックアップ用のファームウエアプログラムを読み出す。このように、生成部132は、既に生成したテーブルを再利用することによって、テーブルの生成処理を省略する。
【0073】
図17は、本発明の実施例5に係るブートローダ116による書込手順を示すフローチャートである。既存のテーブルがあれば(S190のY)、読出部134は、テーブルを読み出す(S192)。既存のテーブルがなければ(S190のN)、取得部130は、スーパーブロックを解析する(S194)。ステップ194からステップ206は、
図14のステップ100からステップ110と同一である。
【0074】
図18は、
図17につづくブートローダ116による書込手順を示すフローチャートである。既存のテーブルがあれば(S220のY)、読出部134は、テーブルを読み出す(S222)。既存のテーブルがなければ(S220のN)、取得部130は、スーパーブロックを解析する(S224)。ステップ224からステップ236は、
図15のステップ130からステップ140と同一である。
【0075】
本発明の実施例によれば、テーブルを共通化することにより、バックアップデータの更新処理時間を短縮できるとともに、バックアップデータを用いたリカバリーの処理時間も短縮できる。また、既存のテーブルを読み出すので、テーブル作成のための時間を削減できる。また、既存のテーブルを読み出すので、処理量を低減できる。
【0076】
(実施例6)
本発明の実施例6は、実施例1においてテーブルを既に生成している場合、テーブルを新たに生成せずに、既に生成したテーブルを利用する場合に相当する。実施例6に係る処理装置100は、
図1と同様のタイプであり、実施例6に係るブートローダ116は、
図7と同様のタイプである。ここでは、これまでの実施例との差異を中心に説明する。
【0077】
実施例1と同様に、HDD104に記憶された更新用のファームウエアプログラムを不揮発性メモリ108に記憶させる際、取得部130は、HDD104や不揮発性メモリ108に、既に生成したテーブルが格納されているかを確認する。テーブルが格納されていなければ、取得部130および生成部132は、実施例1と同様の処理を実行することによって、テーブルを生成する。一方、テーブルが格納されていれば、取得部130および生成部132は、実施例1での処理を省略し、読出部134は、格納されていたテーブルをもとに、スタートアドレスからサイズにわたった連続領域ごとに、HDD104に分割して記憶された更新用のファームウエアプログラムを読み出す。なお、取得部130は、テーブルが格納されていた場合であっても、テーブルの作成日時を確認し、所定の期間よりも前にテーブルが作成されている場合、取得部130および生成部132は、実施例1と同様の処理を実行してもよい。つまり、テーブルが所定の期間よりも新しい場合にのみ、当該テーブルが利用されればよい。
【0078】
図19は、本発明の実施例6に係るブートローダ116による書込手順を示すフローチャートである。既存のテーブルがあれば(S250のY)、読出部134は、テーブルを読み出す(S252)。既存のテーブルがなければ(S250のN)、取得部130は、スーパーブロックを解析する(S254)。ステップ254からステップ266は、
図11のステップ10からステップ20と同一である。
【0079】
本発明の実施例によれば、既存のテーブルを読み出すので、テーブル作成のための時間を削減できる。また、テーブル作成のための時間が削減されるので、ファームウエアプログラムの更新時間を短縮できる。また、同じ更新用のファームウエアプログラムを用いて処理を再試行したい場合や、生産時に予め書き込んでおくような場合に、処理期間を短縮できる。
【0080】
以上、本発明を実施例をもとに説明した。この実施例は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
【0081】
実施例1から7の任意の組合せも有効である。本変形例によれば、実施例1から7の任意の組合せによる効果が得られる。
【0082】
実施例1から7において、ブートローダ116は、ファームウエアプログラムを処理の対象にしている。しかしながらこれに限らず例えば、ブートローダ116は、ファームウエアプログラム以外のファイルを処理に対象にしてもよい。本変形例によれば、さまざまな種類のファイルの読出処理や書込処理に本発明を適用できる。
【0083】
実施例1から7において、HDD104でのファイルシステムとして、ext2ファイルシステムを説明の対象にしている。しかしながらこれに限らず例えば、HDD104でのファイルシステムとして、ext2以外のファイルシステム、ext3が使用されてもよい。本変形例によれば、さまざまな種類のファイルシステムに対して、本発明を適用できる。