WO2010035596A1 - ファームウェア更新装置及び方法 - Google Patents

ファームウェア更新装置及び方法 Download PDF

Info

Publication number
WO2010035596A1
WO2010035596A1 PCT/JP2009/064603 JP2009064603W WO2010035596A1 WO 2010035596 A1 WO2010035596 A1 WO 2010035596A1 JP 2009064603 W JP2009064603 W JP 2009064603W WO 2010035596 A1 WO2010035596 A1 WO 2010035596A1
Authority
WO
WIPO (PCT)
Prior art keywords
update
firmware
normal
file
emergency
Prior art date
Application number
PCT/JP2009/064603
Other languages
English (en)
French (fr)
Inventor
伸之 大浜
雄一 中村
Original Assignee
日立ソフトウエアエンジニアリング株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 日立ソフトウエアエンジニアリング株式会社 filed Critical 日立ソフトウエアエンジニアリング株式会社
Priority to EP09816013A priority Critical patent/EP2330507A4/en
Priority to US13/054,943 priority patent/US8549510B2/en
Priority to CN200980137476.7A priority patent/CN102165422B/zh
Publication of WO2010035596A1 publication Critical patent/WO2010035596A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • G06F8/66—Updates of program code stored in read-only memory [ROM]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates

Definitions

  • the present invention relates to a firmware updating apparatus and method.
  • firmware If a defect is found in all data stored in advance in the non-volatile storage memory of the embedded device, such as the OS or application (hereinafter referred to as "firmware") after releasing the embedded device, the firmware is resolved Conventionally, a method of solving the problem by rewriting to the firmware has been generally practiced.
  • Patent Document 1 discloses a system adopting a two-sided configuration in which two versions of a new firmware and a current firmware are stored.
  • the new firmware and the current firmware can be manually switched by an external console.
  • the update can be completed.
  • the update status is managed, it is possible to resume the update not from the beginning but from the point of failure.
  • the system can be booted by switching from a new firmware to a previous version of firmware. That is, there is an advantage that the update can be resumed even if a failure occurs during the update, or can be returned to the previous version.
  • Japanese Patent Application Laid-Open No. 11-110218 Japanese Patent Application Laid-Open No. 11-110218
  • the present invention has been made in view of such a situation, and is capable of resuming updating at the time of a failure during updating, and has the same fault resistance as the conventional two-sided configuration that it is possible to return to the previous version.
  • non-volatile memory for storing firmware can be saved, system stop due to boot failure can be prevented, and a firmware update process that does not necessarily require restart can be provided.
  • the present invention is a firmware update device having firmware and having a function of updating the firmware, and an operation processing unit that executes firmware update processing in file units according to an update program. And a volatile memory for temporarily storing data, and a non-volatile memory for permanently storing data.
  • the non-volatile memory holds the normal firmware operating at normal times and the emergency firmware operating at an emergency including this normal firmware rewriting failure.
  • the emergency firmware has a size smaller than that of the normal firmware, and has only a function to make the update program executable. Then, when performing the normal firmware update process, the arithmetic processing unit sets the next boot destination as the emergency firmware before the update process and executes the update process, and normally performs the next boot destination after the update process. It is set to the firmware.
  • the non-volatile memory also has a temporary save area for temporarily storing the file before update, and an update data area for storing the update file.
  • the arithmetic processing unit stores the pre-update file in the temporary save area, executes the update process, and then deletes the pre-update file stored in the temporary save area from the temporary save area and the corresponding update file And store it in the update data area.
  • the capacity of the temporary save area is usually set to the capacity of the file of the largest size among the plurality of files constituting the firmware.
  • the non-volatile memory has an update procedure description area in which the update procedure is described, and an update status description area in which the update status of each file constituting the normal firmware is described.
  • the arithmetic processing unit executes the update program in accordance with the update procedure, and writes the update log in the update status description area.
  • the update procedure further includes, for each file constituting the normal firmware, information as to whether or not it is necessary to restart when the update process is completed. In this case, the arithmetic processing unit restarts the file that needs to be restarted after the update processing is completed.
  • the arithmetic processing unit checks whether or not the file necessary for normal firmware boot is damaged, and sets the next boot destination to the normal firmware after executing the update process.
  • the arithmetic processing unit determines whether or not the normal firmware can be activated when the emergency firmware is activated, and sets the next boot destination as the normal firmware if the activation is possible. On the other hand, if the boot is not bootable, the normal firmware is restored using the file before updating stored in the temporary save area to make the bootable state, and the next boot destination is set to the normal firmware.
  • the present invention in firmware update, while saving the capacity of nonvolatile memory for storing firmware, it is equivalent to the conventional two-sided configuration that restart of update at the time of updating failure and restoration to the previous version are possible. Can maintain the credibility of In addition, the system can be prevented from stopping due to a boot failure. In addition, the system downtime due to restart can be minimized.
  • the present invention relates to a firmware updating apparatus having fault tolerance such as being able to cope with problems during updating while reducing the capacity of flash memory storing firmware.
  • FIG. 1 is a view showing a schematic configuration of an embedded device according to an embodiment of the present invention.
  • this embedded device is a home appliance such as a TV.
  • the embedded device 1 includes an MPU (CPU) 11, a RAM 12, a FROM 13, an input device 14, a display device 15, a communication device 16, and a bus 17 for connecting them.
  • the FROM 13 is a non-volatile memory holding firmware.
  • the FROM 13 is urgently activated when there is a failure in the boot block 1301 which is initially executed when the embedded device 1 starts up, a normal firmware block 1302 used in a normal state with no failure in the embedded device 1, and the embedded device 1.
  • the boot block 1301 stores a boot loader 1301A, which is software that is initially executed at the time of activation of the apparatus and is activated from firmware set (designated) at the time of activation.
  • the boot loader reads either the normal firmware block 1302 or the emergency firmware block 1303 after startup.
  • the next boot destination is registered in advance by the MPU 11 as to which one of the normal firmware block 1302 and the emergency firmware block 1303 is to be activated.
  • the base firmware (OS) 1302 A and the base application software 1302 B are stored in the base firmware block 1302.
  • the emergency firmware block 1303 has emergency function software 1303 A which has only a minimum function and which has a smaller size than the normal infrastructure software 1302 A. That is, the infrastructure software for emergency 1303A mounts the update program storage block 1304, the update data storage block 1305, and the normal firmware block 1302 on the RAM and calls the function, that is, enables the updated program to be run. Has only features. Unlike in the past, there is usually no need to have the same foundation software.
  • the update program storage block 1304 stores an update program used when updating the base software 1302A and the normal application software 1302B.
  • the update data storage block 1305 includes update data 1305A, which is difference data between current firmware and new firmware in units of files for updating to new firmware, and an update procedure (how to execute the update according to the procedure and operation Update procedure 1305 B for recording the update procedure storage path for specifying the update procedure being executed and the update status for recording the update procedure execution end position indicating which part of the update procedure has been completed (Log file) 1305C is stored.
  • update data 1305A is difference data between current firmware and new firmware in units of files for updating to new firmware
  • Update procedure (how to execute the update according to the procedure and operation
  • Update procedure 1305 B for recording the update procedure storage path for specifying the update procedure being executed and the update status for recording the update procedure execution end position indicating which part of the update procedure has been completed (Log file) 1305C is stored.
  • updating is performed in units of files, whereas in the past, updating was performed in units of images (lumps of binary data).
  • FIG. 2 is a flowchart illustrating an operation immediately after startup of the normal firmware block 1302 according to an embodiment of the present invention.
  • the MPU 11 determines whether firmware update processing is in progress (step S201). This is determined based on whether the update procedure storage path in the update status 1305C is NULL. It is not NULL if updating is in progress, and NULL if updating is not in progress. If it is determined that the update is in progress, the process proceeds to step 207. If it is determined that the update is not in progress, the process proceeds to step S202.
  • step S202 the MPU 11 determines whether to update the firmware. For example, using the input device 14 and the display device 15, the MPU 11 holds a flag indicating whether the user of the embedded device 1 is inquired, the update data 1305A is newly updated, or the update has already ended normally. Leave it as it is. If not updated, the process proceeds to step S203, the MPU 11 executes a normal start-up procedure (step 203), and ends the process.
  • the MPU 11 determines whether the update is in the forward direction or the reverse direction (step 204). This is realized, for example, by the MPU 11 inquiring the user of the embedded device 1 using the input device 14 and the display device 15. If it is the forward direction, the process proceeds to step S205, and the MPU 11 sets the storage position of the update procedure manual 1305B in the update status 1305C (step S205). On the other hand, if it is the reverse direction, the process proceeds to step S206, the MPU 11 generates the update procedure manual in the reverse direction based on the update procedure manual 1305B, and sets the storage position of the update procedure manual 1305B in the update status 1305C ( Step S206).
  • the MPU 11 sets the next boot destination to the emergency firmware block for the boot loader (step 207).
  • This is a process for enabling the update ahead because the firmware is in the middle of updating. For example, if the power is turned off while rewriting the base software 1302A, the user can not usually start up the base software, and the maker has to collect it. Therefore, in such a case, the update program is executed using the emergency firmware. The next time it stands up, it starts up from the emergency firmware block, so that the process of FIG. 3A or 3B is executed.
  • the MPU 11 executes the firmware update process based on the marching procedure (step S208). The details of the updating process will be further described in FIG.
  • the MPU 11 sets the next boot destination to the normal firmware block for the boot loader (step S209).
  • the MPU 11 determines whether or not the updated file needs to be restarted in the update procedure (step S210). If necessary, the MPU 11 restarts the necessary components in accordance with the update procedure (step S211), and ends. In the case of the two-sided configuration, a restart is always required when updating, but in the case of the present invention, if the update is completed normally, a restart is not necessary, and the abnormality (power drops during updating If there is a problem, etc., it will only need to be restarted (with regard to rewriting of the OS, depending on the target of rewriting, it may be necessary to restart even if updating is completed normally).
  • the update procedure manual includes, for example, the current version before update, the new version after update, and the update content
  • the update content is a restart target representing an operation content, a target file, and a target requiring restart for each target file. It consists of
  • the update target for example, designates the service when the update in service unit is sufficient, and designates the entire system when it is necessary to restart the entire system.
  • deletion of the file generation is changed to generation for the deletion.
  • FIG. 3 (a) is an operation immediately after activation of the emergency firmware block, and is a flow chart for explaining the operation in the case where the normal firmware can be activated if at least the firmware is modified.
  • the MPU 11 determines whether firmware update processing is in progress (step S301). This is determined based on whether the update procedure storage path in the update status 1305C is NULL, as described above. It is not NULL if updating is in progress, or NULL if updating is not in progress. If it is determined that the updating is in progress, the process proceeds to step S303. If it is determined that the update is not in progress, the process proceeds to step S302, the MPU 11 executes a normal start-up procedure (step 302), and ends the process.
  • step S303 the MPU 11 mounts the normal firmware block on the RAM 12.
  • FIG. 3A is related to the case of starting from the normal firmware.
  • the MPU 11 checks whether or not there is a defect in the normal firmware block, and determines whether or not start-up is possible as it is (step S304). If it is determined that the firmware can not be booted, the process proceeds to step S305, and the MPU 11 restores the normal firmware block to the state before the update and makes it bootable (step S305). For example, after the file before update is stored in the update file temporary save block 1306, if the power is turned off during the updating process, the file before update is stored in the update file temporary save block 1306. It is processing of taking out and returning to the state before updating. On the other hand, if it is determined that activation is possible, the process proceeds to step S306.
  • the MPU 11 sets the next boot destination to the normal firmware (step S306), and restarts (step S307). If you get up from the emergency firmware, it will always restart.
  • FIG. 3B is an operation immediately after activation of the emergency firmware block, and is a flowchart for explaining the operation when the normal firmware block can not be activated.
  • FIG. 3 (b) shows the basic operation.
  • the MPU 11 determines whether firmware update processing is in progress (step 311). The determination as to whether the update is in progress is as described above. If it is determined that the update is in progress, the process proceeds to step S313. If it is determined that the update is not in progress, the MPU 11 executes a normal start-up procedure (step 312), and ends the process.
  • step S313 the MPU 11 mounts the normal firmware block on the RAM 12.
  • step S314 the MPU 11 executes an update process. Also, the MPU 11 sets the next boot destination to the normal firmware (step S315) and restarts (step S316).
  • step S314 whether or not the boot is possible is determined by confirming the file corruption status necessary for booting.
  • another OS provided on the emergency firmware area on the OS.
  • FIG. 4 is a flowchart for explaining the details of the firmware update process.
  • step S401 if there is a damaged file in the previous update process, the MPU 11 discards it (step S401). This is because, for example, when the power is turned off in the middle of updating, a file generated by the updating process may include a damaged file (a file which has been updated only halfway). Discarding such a damaged file is the process of step S401.
  • the update process is performed on a file basis, and it can be determined from the update status 1305C that up to which file the update process has been completed can be detected, so that the file being updated can be detected.
  • the MPU 11 determines the update start position based on the update procedure 1305B and the update status 1305C (step S402), and saves the copy of the update target file in the update file temporary save block 1306 (step S403).
  • the MPU 11 updates the file to be updated according to the update procedure 1305B (step S404).
  • the MPU 11 deletes the corresponding update file (update files A, B,...) In the update data 1305A, and instead saves the backup file (file before update) stored in the update file temporary save block 1306 ) To the update data 1305A (step 405).
  • a backup area simply exists, and the file before update is stored in the backup area.
  • the firmware capacity can be saved by performing step S405.
  • the capacity of the update file temporary save block 1306 is determined in advance as the maximum file size of the embedded device 1.
  • the MPU 11 determines whether or not there is a problem during the update process of step S404 (step 406), and if it is determined that there is a problem, the process proceeds to step S407, and it is determined that there is no problem. The processing shifts to step S408.
  • step S407 the MPU 11 restarts the foundation software (normal or emergency foundation software), and starts the process of FIG. 2 or 3 from the beginning.
  • step S408 the MPU 11 checks whether the update process has been completed for all files. If any file has not been updated, the process returns to step S403. If all files have been updated, the process proceeds to step S409.
  • step S409 the MPU 11 initializes the update status 1305C, and the update processing ends. When the update process is completed, the process proceeds to step S209 in FIG. 2 or step S315 in FIG. 3 (b).
  • step S405 the updated file is temporarily stored in the update file temporary save block 1306, and then the corresponding file in the update data is deleted. Instead, the file before update is updated data storage area The file may be moved to the normal firmware block after the update.
  • a boot loader for reading firmware into nonvolatile memory, normal firmware operating normally and emergency firmware operating in an emergency such as normal firmware rewrite failure, an update program accessible from both firmwares, normal Update data consisting only of files that have changed among firmware, update procedure describing update method, update status to record progress of update, temporarily store previous file or updated file during file update Hold the update file temporary backup area. Then, configuring the update data with only the file having a change in the normal firmware, making the update file temporary save area a capacity of a predetermined maximum file size, and changing the file before the update after the file update The non-volatile memory capacity is reduced by storing it in the area occupied by.
  • configure the configuration that allows access to data necessary for updating from both normal firmware and emergency and set the next boot destination as emergency firmware immediately before the update, and set the next boot destination as normal firmware immediately after the update is completed.
  • a virtualization environment is prepared in the emergency firmware area during emergency firmware activation, and another OS can be operated in the OS, and it is actually confirmed that normal firmware can be activated. As a result, it is possible to prevent the system from shutting down due to startup failure at the time of subsequent normal firmware startup.
  • the present invention can also be realized by a program code of software that realizes the functions of the embodiment.
  • a storage medium storing the program code is provided to the system or apparatus, and a computer (or CPU or MPU) of the system or apparatus reads the program code stored in the storage medium.
  • the program code itself read from the storage medium implements the functions of the above-described embodiments, and the program code itself and the storage medium storing the same constitute the present invention.
  • a storage medium for supplying such a program code for example, a flexible disk, a CD-ROM, a DVD-ROM, a hard disk, an optical disk, an optical magnetic disk, a CD-R, a magnetic tape, a non-volatile memory card, a ROM Etc. are used.
  • an OS Operating System
  • the CPU of the computer or the like performs part or all of the actual processing based on the instruction of the program code, and the processing.
  • the storage means such as a hard disk or memory of a system or apparatus or a storage medium such as a CD-RW or CD-R
  • the computer (or CPU or MPU) of the system or apparatus may read out and execute the program code stored in the storage means or the storage medium at the time of use.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)

Abstract

　ファームウェア保存用の不揮発性メモリ容量を小さく抑えながらも、更新中不具合に対応でき、更新に伴うシステム停止時間の短いファームウェア更新装置を提供する。更新に必要なデータを通常ファームウェアと緊急用ファームウェアの両方からアクセス可能な構成とし、更新の間次回ブート先を緊急用ファームウェアに設定しておく手段と、更新ファイルが元々占有していた領域に更新前のファイルを退避する手段と、緊急用ファームウェア起動中に通常ファームウェアのブートに必要なファイルが壊れていないことを検査するもしくは、仮想化環境により実際に起動が可能であることを確かめる手段と、退避した更新前ファイルと、更新手順から操作内容を反転させることで自動生成した新たな更新手順によって、更新前の状態に戻す手段と、更新手順に更新ファイルごとに必要な再起動の対象を記述しておく手段を備える。

Description

ファームウェア更新装置及び方法
　本発明は、ファームウェア更新装置及び方法に関する。
　組込み装置をリリースした後、組み込み装置の不揮発性記憶メモリにあらかじめ記憶されている全てのデータ、例えばＯＳやアプリケーション（以下、「ファームウェア」という）に関して不具合が見つかった場合、当該ファームウェアを不具合を解決したファームウェアに書き換えることによって、不具合を解決するという方法が従来から一般に行われている。
　例えば、特許文献１には、新しいファームウェアと現在のファームウェアの２つのバージョンを保有するという２面構成を採用するシステムが開示されている。ここでは、新しいファームウェアと現在のファームウェアは外部のコンソールにより、手動で切り替えることができるようになっている。特許文献１によれば、更新途中で電源が落ちたり、想定外の操作をしてしまうなど更新中不具合があり、更新が途中で終了してしまった場合でも、外部のコンソールから更新を初めからやり直すことで、更新を完了させることができる。また、更新状況を管理しておけば、初めからではなく不具合発生時点から更新を再開することも可能である。さらに、新しいファームウェアから前のバージョンのファームウェアに切り替えることで、システムを起動することができる。つまり、更新中不具合が発生しても更新を再開できたり、前のバージョンに戻すことができるという利点がある。
特開平１１－１１０２１８号公報
　しかしながら、特許文献１に開示されたファームウェア更新装置は２面構成を採用しているため、バックアップを持たないものに比べてファームウェア容量が２倍要り、装置の開発コストが高くなるという欠点がある。また、ブートができない状態に陥った場合、それを直すために、必ず外部コンソールが必要であり、一般ユーザが自分で簡単に修正することができない。
　さらに、該装置では、装置を停止させてファームウェアの更新を行うため、更新後の起動処理を行う必要がある。装置を停止させずにファームウェアを書き換える他のファームウェア更新装置でも、書き換えた後、必ず装置の再起動を必要とする。このように常に再起動を必要とするとファームウェア更新処理に時間が掛かってしまう。
　本発明はこのような状況に鑑みてなされたものであり、更新中不具合時に更新の再開が可能であり、前のバージョンに戻すことができるという従来の２面構成と同等の耐障害性を有しつつも、ファームウェア保存用の不揮発性メモリを節約でき、ブート失敗によるシステム停止を防ぐことができ、かつ必ずしも再起動を必要としないファームウェア更新処理を提供するものである。
　上記課題を解決するために、本発明は、ファームウェアを有し、このファームウェアを更新する機能を備えるファームウェア更新装置であって、更新プログラムに従って、ファイル単位でファームウェアの更新処理を実行する演算処理部と、一時的にデータを保存する揮発性メモリと、持続的にデータを保存する不揮発性メモリと、を備える。そして、不揮発性メモリは、通常時に動作する通常ファームウェアと、この通常ファームウェア書き換え失敗時を含む緊急時に動作する緊急用ファームウェアと、を保持する。ここで、緊急用ファームウェアは、通常ファームウェアよりサイズが小さく、更新プログラムを実行できる状態にする機能のみを有する。そして、演算処理部は、通常ファームウェアの更新処理をする場合には、更新処理の前に次回のブート先を緊急用ファームウェアに設定して更新処理を実行し、更新処理の後に次回ブート先を通常ファームウェアに設定するようにしている。
　また、不揮発メモリは、更新前のファイルを一時的に格納するための一時退避領域と、更新ファイルを格納する更新データ領域と、を有する。この場合、演算処理部は、更新前のファイルを一時退避領域に格納し、更新処理を実行した後、一時退避領域に格納した更新前のファイルを一時退避領域から削除すると共に、対応する更新ファイルと入れ替えて更新データ領域に格納するようにする。なお、一時退避領域の容量は、通常ファームウェアを構成する複数のファイルのうち最大サイズのファイルの容量に設定されている。
　さらに、不揮発性メモリは、更新手順を記載した更新手順記載領域と、通常ファームウェアを構成する各ファイルについての更新状況を記載した更新状況記載領域と、を有している。この場合、演算処理部は、更新手順に従って更新プログラムを実行し、更新のログを更新状況記載領域に記述する。ここで、更新手順は、さらに、通常ファームウェアを構成する各ファイルについて、更新処理が完了した場合に再起動が必要か否かについての情報を含んでいる。この場合、演算処理部は、更新処理終了後に、再起動が必要とされるファイルについて再起動する。
　演算処理部は、緊急用ファームウェアを起動した場合に、通常ファームウェアのブートに必要なファイルの破損の有無をチェックし、更新処理を実行した後に、次回ブート先を通常ファームウェアに設定する。
　また、演算処理部は、緊急用ファームウェアを起動したとき、通常ファームウェアが起動可能か否かを判断し、起動可能な場合には、次回ブート先を通常ファームウェアに設定する。一方、起動可能でない場合には、一時退避領域に格納された更新前のファイルを用いて前記通常ファームウェアを修復して起動可能な状態にしてから、次回ブート先を前記通常ファームウェアに設定する。
　さらなる本発明の特徴は、以下本発明を実施するための最良の形態および添付図面によって明らかになるものである。
　本発明によれば、ファームウェア更新において、ファームウェア保存用の不揮発性メモリの容量を節約しながらも、更新中不具合時の更新再開と前のバージョンへの戻すことができるという従来の２面構成と同等の信頼性を保つことができる。また、ブート失敗によるシステム停止を防ぐことができる。また、再起動によるシステム停止時間を必要最小限に留めることができる。
本発明の実施形態における組込み装置の概略構成を示す図である。 通常ファームウェアブロックの起動直後の動作を説明するためのフローチャートである。 緊急用ファームウェアブロックの起動直後の動作を説明するためのフローチャート（１）である。 緊急用ファームウェアブロックの起動直後の動作を説明するためのフローチャート（２）である。 ファームウェアの更新処理の詳細動作を説明するためのフローチャートである。
　本発明は、ファームウェアを格納するフラッシュメモリの容量を削減しながらも、更新中の不具合にも対応できるなどの耐障害性を有するファームウェア更新装置に関するものである。
　以下、添付図面を参照して本発明の実施形態について説明する。ただし、本実施形態は本発明を実現するための一例に過ぎず、本発明の技術的範囲を限定するものではないことに注意すべきである。
　＜組込み装置（ファームウェア更新装置）の構成＞
　図１は本発明の実施形態による組込み装置の概略構成を示す図である。本発明において、この組込み装置として想定しているものは例えばＴＶなどの家電機器である。
　組込み装置１は、ＭＰＵ（ＣＰＵ）１１と、ＲＡＭ１２と、ＦＲＯＭ１３と、入力装置１４と、表示装置１５と、通信装置１６と、それぞれを接続するバス１７と、で構成されている。
　ＦＲＯＭ１３はファームウェアを保持している不揮発性メモリである。ＦＲＯＭ１３は、組込み装置１の起動時に最初に実行されるブートブロック１３０１と、組込み装置１に不具合のない通常状態で利用される通常ファームウェアブロック１３０２と、組込み装置１に不具合のあった場合に緊急に利用される緊急用ファームウェアブロック１３０３と、ファームウェア更新時に利用される更新プログラム保存ブロック１３０４と、ファームウェア更新時に利用される更新データ保存ブロック１３０５と、更新ファイルを一時的に格納する更新ファイル一時退避ブロック１３０６と、によって構成されている。
　ブートブロック１３０１には、本装置起動時最初に実行され、起動時に設定（指定）したファームウェアから起動させるためのソフトウェアであるブートローダ１３０１Ａが保存されている。ブートローダは、起動後、通常ファームウェアブロック１３０２もしくは緊急用ファームウェアブロック１３０３のいずれかを読み込む。ブートローダ１３０１Ａには、通常ファームウェアブロック１３０２及び緊急用ファームウェアブロック１３０３のいずれから起動するか、あらかじめ次回ブート先がＭＰＵ１１によって登録される。
　通常ファームウェアブロック１３０２には、通常基盤ソフトウェア（ＯＳ）１３０２Ａと通常応用ソフトウェア１３０２Ｂが保存されている。
　緊急用ファームウェアブロック１３０３には、最低限の機能のみ有し、通常基盤ソフトウェア１３０２Ａに比べてサイズを小さく抑えた緊急用基盤ソフトウェア１３０３Ａが保存される。つまり、緊急用基盤ソフトウェア１３０３Ａは、更新プログラム保存ブロック１３０４と更新データ保存ブロック１３０５と通常ファームウェアブロック１３０２とをＲＡＭにマウントして呼び出すだけの機能、即ち更新したプログラムを走らせることができる状態にする機能のみを備えている。従来とは異なり、通常基盤ソフトウェアと同じものを備えている必要はない。
　更新プログラム保存ブロック１３０４には、通常基盤ソフトウェア１３０２Ａと通常応用ソフトウェア１３０２Ｂを更新する際に用いる更新プログラムが保存されている。
　更新データ保存ブロック１３０５には、新しいファームウェアに更新するための、現在のファームウェアと新しいファームウェアのファイル単位の差分データである更新データ１３０５Ａと、更新手順（どのような手順及び操作で更新を実行するか）を記録する更新手順１３０５Ｂと、実行中の更新手順を指定する更新手順格納パスと該更新手順の中のどの部分まで終了しているかを表す更新手順実行終了位置とを記録するための更新状況（ｌｏｇ　ｆｉｌｅ）１３０５Ｃと、が保存されている。従来ではイメージ（バイナリデータの塊）単位で更新していたのに対し、本発明ではファイル単位での更新を行っている。
　＜通常ファームウェアの動作＞
　図２は、本発明の実施形態による通常ファームウェアブロック１３０２の起動直後の動作を説明するためのフローチャートである。
　最初に、ＭＰＵ１１は、ファームウェア更新処理が途中であるか否かについて判定する（ステップＳ２０１）。これは、更新状況１３０５Ｃの中の更新手順格納パスがＮＵＬＬか否かで判定する。更新途中である場合はＮＵＬＬではなく、更新途中でない場合はＮＵＬＬとなっている。更新途中と判定された場合、処理はステップ２０７に進み、更新途中でないと判定された場合、処理はステップＳ２０２に移行する。
　ステップＳ２０２において、ＭＰＵ１１は、ファームウェア更新を行うかどうか判定する。例えば、ＭＰＵ１１が入力装置１４と表示装置１５を利用して、組込み装置１のユーザに問い合わせるか、もしくは更新データ１３０５Ａに更新を新規に行うのか、既に更新が正常終了したのかを示すフラグを保有しておき、それを参照するようにする。更新しない場合には、処理はステップＳ２０３に移行し、ＭＰＵ１１は通常の起動手順を実行し（ステップ２０３）、処理を終了する。
　ファームウェアを更新する場合には、ＭＰＵ１１は、その更新が順方向か逆方向かを判定する（ステップ２０４）。これは例えば、ＭＰＵ１１が、組込み装置１のユーザに入力装置１４と表示装置１５を利用して問い合わせることにより実現される。順方向である場合、処理はステップＳ２０５に移行し、ＭＰＵ１１が更新状況１３０５Ｃに更新手順書１３０５Ｂの格納位置を設定する（ステップＳ２０５）。一方、逆方向である場合、処理はステップＳ２０６に移行し、ＭＰＵ１１が更新手順書１３０５Ｂを元に逆方向の更新手順書を生成し、更新状況１３０５Ｃに更新手順書１３０５Ｂの格納位置を設定する（ステップＳ２０６）。
　続いて、ＭＰＵ１１は、ブートローダに対し、次回ブート先を緊急用ファームウェアブロックに設定する（ステップ２０７）。これは、ファームウェアが更新途中になっているので、その先の更新を可能にするための処理である。例えば、通常基盤ソフトウェア１３０２Ａを書き換えている途中で電源が落ちてしまったような場合、ユーザは通常基盤ソフトウェアを起動することできず、メーカが回収しなければならなくなるからである。よって、このような場合には、緊急用ファームウェアを用いて更新プログラムを実行するようにしている。次回立ち上がるときは緊急用ファームウェアブロックから立ち上がるので、処理としては図３（ａ）又は（ｂ）の処理が実行されることになる。
　そして、ＭＰＵ１１は、ファームウェアの更新処理を行進手順書に基づいて実行する（ステップＳ２０８）。更新処理の詳細は図４でさらに説明する。
　次に、ＭＰＵ１１は、ブートローダに対し、次回ブート先を通常ファームウェアブロックに設定する（ステップＳ２０９）。
　さらに、ＭＰＵ１１は、更新したファイルについて再起動が必要かどうかを更新手順書で判定する（ステップＳ２１０）。必要な場合は、ＭＰＵ１１は、更新手順書に従って必要なコンポーネントに対し再起動し（ステップＳ２１１）、終了する。２面構成の場合には更新した場合には必ず再起動が必要であったが、本発明の場合には正常に更新が完了すれば再起動は不要であり、異常（更新途中で電源が落ちた等）があった場合に再起動が必要となるだけである（ＯＳの書き換えに関しては書き換えの対象によっては正常に更新が終了しても再起動が必要な場合はある）。
　なお、更新手順書は、例えば、更新前の現バージョン、更新後の新バージョン、更新内容からなり、更新内容は対象ファイルごとに操作内容、対象ファイル、再起動が必要な対象を表す再起動対象からなる。更新対象とは例えば、サービス単位での更新で済む場合はそのサービスを指定し、システム全体を再起動する必要がある場合は、システム全体を指定する。ステップＳ２０６の逆方向の更新手順書の生成について、例えば、ファイルの生成については削除、削除については生成に変更する。
　＜緊急用ファームウェアブロックの動作＞
　緊急用ファームウェアブロックの起動後の動作としては、例えば、図３（ａ）及び（ｂ）に示されるように２種類考えられる。
（１）図３（ａ）は、緊急用ファームウェアブロックの起動直後の動作であり、通常ファームウェアが少なくとも修正すれば起動可能であった場合の動作を説明するためのフローチャートである。
　最初に、ＭＰＵ１１は、ファームウェア更新処理が途中であるか否かについて判定する（ステップＳ３０１）。これは、前述と同様に、更新状況１３０５Ｃの中の更新手順格納パスがＮＵＬＬか否かで判定する。更新途中である場合はＮＵＬＬではなく、更新途中でない場合はＮＵＬＬである。更新途中と判定された場合、処理はステップＳ３０３に進む。更新途中でないと判定された場合、処理はステップＳ３０２に移行し、ＭＰＵ１１は通常の起動手順を実行し（ステップ３０２）、処理を終了する。
　ステップＳ３０３において、ＭＰＵ１１は、通常ファームウェアブロックをＲＡＭ１２にマウントする。図３（ａ）は通常ファームウェアから起動する場合に係るからである。
　そして、ＭＰＵ１１は、通常ファームウェアブロックに欠陥があるか否か検査し、そのままで起動可能か判定する（ステップＳ３０４）。起動できないと判断された場合、処理はステップＳ３０５に移行し、ＭＰＵ１１は通常ファームウェアブロックを更新前の状態に戻して、起動可能にする（ステップＳ３０５）。例えば、更新前のファイルを更新ファイル一時退避ブロック１３０６に格納した後、更新処理している途中で電源が落ちてしまったような場合には、この更新ファイル一時退避ブロック１３０６から更新前のファイルを取り出して更新前の状態に戻す、といった処理である。一方、起動可能と判断された場合、処理はステップＳ３０６に移行する。
　続いて、ＭＰＵ１１は、次回ブート先を通常ファームウェアに設定し（ステップＳ３０６）、再起動する（ステップＳ３０７）。緊急用ファームウェアから立ち上がった場合には必ず再起動することになる。
（２）図３（ｂ）は、緊急用ファームウェアブロックの起動直後の動作であり、通常ファームウェアブロックが起動可能でない場合の動作を説明するためのフローチャートである。図３（ｂ）の方が基本となる動作を示している。
　最初に、ＭＰＵ１１は、ファームウェア更新処理が途中であるか否かについて判定する（ステップ３１１）。更新途中であるか否かの判断については上述した通りである。更新途中と判定された場合、処理はステップＳ３１３に進む。更新途中でないと判定された場合は、ＭＰＵ１１は、通常の起動手順を実行し（ステップ３１２）、処理を終了する。
　ステップＳ３１３では、ＭＰＵ１１は、通常ファームウェアブロックをＲＡＭ１２にマウントする。
　そして、ＭＰＵ１１は、更新処理を実行する（ステップＳ３１４）。また、ＭＰＵ１１は、次回ブート先を通常ファームウェアに設定し（ステップＳ３１５）、再起動する（ステップＳ３１６）。
　なお、ステップＳ３１４では、ブートに必要なファイルの破損状況を確認することでブート可能かどうかを判定しているが、その代わりもしくはそれに加え、緊急用ファームウェア領域内に備えた、ＯＳ上で別のＯＳを動作させることのできる仮想化環境により、通常ファームウェアの起動が可能であることを実際に確かめても良い。
　＜ファームウェアの更新処理＞
　図４は、ファームウェアの更新処理の詳細について説明するためのフローチャートである。
　まず、ＭＰＵ１１は、前回の更新処理において破損ファイルがあれば破棄する（ステップＳ４０１）。これは、例えば、更新途中で電源が落ちてしまったような場合には更新処理によって生成されたファイルに破損ファイル（途中までしか更新されていないファイル）が含まれている場合がある。このような破損ファイルを破棄するのがステップＳ４０１の処理である。ファイル単位で更新処理が行われ、どのファイルまで更新処理が完了しているかは更新状況１３０５Ｃを見れば分かるので更新途中のファイルが検出できる。
　次に、ＭＰＵ１１は、更新手順１３０５Ｂと更新状況１３０５Ｃを基に更新開始位置を判定し（ステップＳ４０２）、更新対象ファイルの複製を更新ファイル一時退避ブロック１３０６に退避する（ステップＳ４０３）。
　そして、ＭＰＵ１１は、更新手順１３０５Ｂに従って、更新対象ファイルを更新する（ステップＳ４０４）。
　続いて、ＭＰＵ１１は、更新データ１３０５Ａの中の該当更新ファイル（更新ファイルＡ、Ｂ、・・・）を削除し、代わりに更新ファイル一時退避ブロック１３０６に格納されていた退避ファイル（更新前のファイル）を更新データ１３０５Ａに移動する（ステップ４０５）。従来は単純にバックアップ領域が存在し、該バックアップ領域に更新前のファイルを格納していたが、本発明でステップＳ４０５のようにすることで、ファームウェア容量を節約することができる。なお、更新ファイル一時退避ブロック１３０６の容量は、あらかじめ組込み装置１の最大ファイルサイズに決定されている。
　さらに、ＭＰＵ１１は、ステップＳ４０４の更新処理中に不具合があったかどうか判定をし（ステップ４０６）、不具合があったと判断された場合、処理はステップＳ４０７に移行し、不具合がなかったと判断された場合、処理はステップＳ４０８に移行する。
　ステップＳ４０７では、ＭＰＵ１１は、基盤ソフトウェア（通常又は緊急基盤ソフトウェア）を再起動し、図２又は図３の処理を最初から開始する。一方、ステップＳ４０８では、ＭＰＵ１１は、全てのファイルについて更新処理が完了したか否か調べる。何れかのファイルについて更新済みで無い場合は、処理はステップＳ４０３に戻り、全ファイル更新済みである場合は、処理はステップＳ４０９に移行する。ステップＳ４０９では、ＭＰＵ１１は、更新状況１３０５Ｃを初期化し、更新処理が終了する。更新処理が終了した場合には、処理は、図２のステップＳ２０９又は図３（ｂ）のステップＳ３１５に移行する。
　なお、ステップＳ４０３からステップＳ４０５の処理に関しては、更新ファイル一時退避ブロック１３０６に更新後のファイルを格納し、その後、更新データ中の該当ファイルを削除し、代わりに更新前のファイルを更新データ保存領域へ移動し、更新後ファイルを通常ファームウェアブロックに移動しても良い。
　＜まとめ＞
　本発明の実施形態では、不揮発性メモリ内に、ファームウェアを読み込むためのブートローダ、通常動作する通常ファームウェアと通常ファームウェア書き換え失敗時など緊急時に動作する緊急用ファームウェア、両ファームウェアからアクセス可能な更新プログラム、通常ファームウェアのうち変更のあるファイルのみで構成される更新データ、更新方法を記した更新手順、更新途中経過を記録する更新状況、ファイル更新中にその前のファイルまたは更新後のファイルを一時的に格納する更新ファイル一時退避領域を保有する。そして、更新データを通常ファームウェアのうち変更のあるファイルのみで構成することと、更新ファイル一時退避領域をあらかじめ決めた最大ファイルサイズの容量にすること、更新前のファイルを該ファイル更新後に更新後ファイルが占有していた領域に格納することで、不揮発性メモリ容量を小さく抑える。
　また、通常ファームウェアと緊急用の両方から更新に必要なデータにアクセス可能な構成と、更新の直前に次回ブート先を緊急用ファームウェアに設定し、更新終了直後に次回ブート先を通常ファームウェアに設定する。これにより、更新中の不具合発生時に、不具合発生時点から更新を再開することができ、退避した更新前ファイルと、更新手順から操作内容を反転させることで自動生成した新たな更新手順によって、更新前の状態に戻すことができるようになっている。
　さらに、緊急用ファームウェア起動中に通常ファームウェアのブートに必要なファイルの破損がないかを検査するようにしている。これにより、その後の通常ファームウェア起動時に起動失敗に陥りシステムが停止してしまうことを回避することができる。
　また、緊急用ファームウェア起動中に緊急用ファームウェア領域内に備えた、ＯＳ内で別のＯＳを動作させることのできる仮想化環境を用意し、通常ファームウェアの起動が可能であることを実際に確かめる。これにより、その後の通常ファームウェア起動時に起動失敗に陥りシステムが停止してしまうことを回避することができるようになる。
　また、稼働中の通常ファームウェアから書き換え、かつ、更新手順に、更新ファイルごとに必要な再起動の対象として、システム全体またはあるサービスまたは一切再起動が必要がないことを記述しておく。これにより、システムの停止時間を必要最小限に抑えることができるようになる。
　なお、本発明は、実施形態の機能を実現するソフトウェアのプログラムコードによっても実現できる。この場合、プログラムコードを記録した記憶媒体をシステム或は装置に提供し、そのシステム或は装置のコンピュータ（又はＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読み出す。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコード自体、及びそれを記憶した記憶媒体は本発明を構成することになる。このようなプログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク、ＣＤ－ＲＯＭ、ＤＶＤ－ＲＯＭ、ハードディスク、光ディスク、光磁気ディスク、ＣＤ－Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭなどが用いられる。
　また、プログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳ（オペレーティングシステム）などが実際の処理の一部又は全部を行い、その処理によって前述した実施の形態の機能が実現されるようにしてもよい。さらに、記憶媒体から読み出されたプログラムコードが、コンピュータ上のメモリに書きこまれた後、そのプログラムコードの指示に基づき、コンピュータのＣＰＵなどが実際の処理の一部又は全部を行い、その処理によって前述した実施の形態の機能が実現されるようにしてもよい。
　また、実施の形態の機能を実現するソフトウェアのプログラムコードを、ネットワークを介して配信することにより、それをシステム又は装置のハードディスクやメモリ等の記憶手段又はＣＤ-ＲＷ、ＣＤ-Ｒ等の記憶媒体に格納し、使用時にそのシステム又は装置のコンピュータ(又はＣＰＵやＭＰＵ)が当該記憶手段や当該記憶媒体に格納されたプログラムコードを読み出して実行するようにしても良い。
１・・・組込み装置
１１・・ＭＰＵ
１２・・・ＲＡＭ
１３・・・ＦＲＯＭ
１４・・・入力装置
１５・・・表示装置
１６・・・通信装置
１３０１・・・ブートブロック
１３０１・・・通常ファームウェアブロック
１３０２・・・更新ファームウェアブロック
１３０３・・・緊急用ファームウェアブロック
１３０４・・・更新プログラム保存ブロック
１３０５・・・更新データ保存ブロック
１３０６・・・更新ファイル一時退避ブロック
１３０１Ａ・・・ブートローダ
１３０２Ａ・・・通常基盤ソフトウェア
１３０２Ｂ・・・通常応用ソフトウェア
１３０３Ａ・・・緊急用基盤ソフトウェア
１３０４Ａ・・・更新プログラム
１３０５Ａ・・・更新データ
１３０５Ｂ・・・更新手順書
１３０５Ｃ・・・更新状況

Claims (14)

  1. 　ファームウェアを有し、このファームウェアを更新する機能を備えるファームウェア更新装置であって、
    　更新プログラムに従って、ファイル単位でファームウェアの更新処理を実行する演算処理部と、
    　一時的にデータを保存する揮発性メモリと、
    　持続的にデータを保存する不揮発性メモリと、を備え、
    　前記不揮発性メモリは、通常時に動作する通常ファームウェアと、この通常ファームウェア書き換え失敗時を含む緊急時に動作する緊急用ファームウェアと、を保持し、
    　前記緊急用ファームウェアは、前記通常ファームウェアよりサイズが小さく、前記更新プログラムを実行できる状態にする機能のみを有し、
    　前記演算処理部は、前記通常ファームウェアの更新処理をする場合には、前記更新処理の前に次回のブート先を前記緊急用ファームウェアに設定して前記更新処理を実行し、前記更新処理の後に次回ブート先を前記通常ファームウェアに設定することを特徴とするファームウェア更新装置。
  2. 　前記不揮発メモリは、更新前のファイルを一時的に格納するための一時退避領域と、更新ファイルを格納する更新データ領域と、を有し、
    　前記演算処理部は、更新前のファイルを前記一時退避領域に格納し、前記更新処理を実行した後、前記一時退避領域に格納した前記更新前のファイルを前記一時退避領域から削除すると共に、対応する前記更新ファイルと入れ替えて前記更新データ領域に格納することを特徴とする請求項１に記載のファームウェア更新装置。
  3. 　前記不揮発性メモリは、更新手順を記載した更新手順記載領域と、前記通常ファームウェアを構成する各ファイルについての更新状況を記載した更新状況記載領域と、を有し、
    　前記演算処理部は、前記更新手順に従って前記更新プログラムを実行し、更新のログを前記更新状況記載領域に記述することを特徴とする請求項１に記載のファームウェア更新装置。
  4. 　前記更新手順は、前記通常ファームウェアを構成する各ファイルについて、更新処理が完了した場合に再起動が必要か否かについての情報を含み、
    　前記演算処理部は、前記更新処理終了後に、再起動が必要とされるファイルについて再起動することを特徴とする請求項３に記載のファームウェア更新装置。
  5. 　前記演算処理部は、前記緊急用ファームウェアを起動した場合に、前記通常ファームウェアのブートに必要なファイルの破損の有無をチェックし、前記更新処理を実行した後に、次回ブート先を前記通常ファームウェアに設定することを特徴とする請求項１に記載のファームウェア更新装置。
  6. 　前記演算処理部は、前記緊急用ファームウェアを起動したとき、前記通常ファームウェアが起動可能か否かを判断し、起動可能な場合には、次回ブート先を前記通常ファームウェアに設定することを特徴とする請求項１に記載のファームウェア更新装置。
  7. 　前記演算処理部は、前記緊急用ファームウェアを起動したとき、前記通常ファームウェアが起動可能か否かを判断し、起動可能でない場合には、前記一時退避領域に格納された更新前のファイルを用いて前記通常ファームウェアを修復して起動可能な状態にしてから、次回ブート先を前記通常ファームウェアに設定することを特徴とする請求項２に記載のファームウェア更新装置。
  8. 　ファームウェアを組込んだ組込み装置において、前記ファームウェアを更新するファームウェア更新方法であって、
    　前記組込み装置は、更新プログラムに従って、ファイル単位でファームウェアの更新処理を実行する演算処理部と、一時的にデータを保存する揮発性メモリと、持続的にデータを保存する不揮発性メモリと、を備え、
    　前記不揮発性メモリは、通常時に動作する通常ファームウェアと、この通常ファームウェア書き換え失敗時を含む緊急時に動作する緊急用ファームウェアと、を保持し、
    　前記緊急用ファームウェアは、前記通常ファームウェアよりサイズが小さく、前記更新プログラムを実行できる状態にする機能のみを有し、
    　前記演算処理部が、前記通常ファームウェアの更新処理をする場合には、前記更新処理の前に次回のブート先を前記緊急用ファームウェアに設定して前記更新処理を実行し、前記更新処理の後に次回ブート先を前記通常ファームウェアに設定するステップを備えることを特徴とするファームウェア更新方法。
  9. 　前記不揮発メモリは、更新前のファイルを一時的に格納するための一時退避領域と、更新ファイルを格納する更新データ領域と、を有し、
    　前記演算処理部が、更新前のファイルを前記一時退避領域に格納し、前記更新処理を実行した後、前記一時退避領域に格納した前記更新前のファイルを前記一時退避領域から削除すると共に、対応する前記更新ファイルと入れ替えて前記更新データ領域に格納するステップを備えることを特徴とする請求項８に記載のファームウェア更新方法。
  10. 　前記不揮発性メモリは、更新手順を記載した更新手順記載領域と、前記通常ファームウェアを構成する各ファイルについての更新状況を記載した更新状況記載領域と、を有し、
    　前記演算処理部が、前記更新手順に従って前記更新プログラムを実行し、更新のログを前記更新状況記載領域に記述するステップを備えることを特徴とする請求項８に記載のファームウェア更新方法。
  11. 　前記更新手順は、前記通常ファームウェアを構成する各ファイルについて、更新処理が完了した場合に再起動が必要か否かについての情報を含み、
    　前記演算処理部が、前記更新処理終了後に、再起動が必要とされるファイルについて再起動するステップを備えることを特徴とする請求項１０に記載のファームウェア更新方法。
  12. 　前記演算処理部が、前記緊急用ファームウェアを起動した場合に、前記通常ファームウェアのブートに必要なファイルの破損の有無をチェックし、前記更新処理を実行した後に、次回ブート先を前記通常ファームウェアに設定するステップを備えることを特徴とする請求項８に記載のファームウェア更新方法。
  13. 　前記演算処理部が、前記緊急用ファームウェアを起動したとき、前記通常ファームウェアが起動可能か否かを判断し、起動可能な場合には、次回ブート先を前記通常ファームウェアに設定するステップを備えることを特徴とする請求項８に記載のファームウェア更新方法。
  14. 　前記演算処理部が、前記緊急用ファームウェアを起動したとき、前記通常ファームウェアが起動可能か否かを判断し、起動可能でない場合には、前記一時退避領域に格納された更新前のファイルを用いて前記通常ファームウェアを修復して起動可能な状態にしてから、次回ブート先を前記通常ファームウェアに設定するステップを備えることを特徴とする請求項９に記載のファームウェア更新方法。
PCT/JP2009/064603 2008-09-24 2009-08-21 ファームウェア更新装置及び方法 WO2010035596A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
EP09816013A EP2330507A4 (en) 2008-09-24 2009-08-21 DEVICE AND METHOD FOR FIRMWARE UPDATE
US13/054,943 US8549510B2 (en) 2008-09-24 2009-08-21 Firmware update apparatus and method
CN200980137476.7A CN102165422B (zh) 2008-09-24 2009-08-21 固件更新装置以及方法

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2008244754A JP5113700B2 (ja) 2008-09-24 2008-09-24 ファームウェア更新装置及び方法
JP2008-244754 2008-09-24

Publications (1)

Publication Number Publication Date
WO2010035596A1 true WO2010035596A1 (ja) 2010-04-01

Family

ID=42059603

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2009/064603 WO2010035596A1 (ja) 2008-09-24 2009-08-21 ファームウェア更新装置及び方法

Country Status (5)

Country Link
US (1) US8549510B2 (ja)
EP (1) EP2330507A4 (ja)
JP (1) JP5113700B2 (ja)
CN (1) CN102165422B (ja)
WO (1) WO2010035596A1 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170099405A1 (en) * 2015-10-02 2017-04-06 Hajime Takayama Control apparatus and control method
US11301229B2 (en) 2018-03-29 2022-04-12 Nec Corporation System update device and system update method

Families Citing this family (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8495618B1 (en) * 2010-03-31 2013-07-23 American Megatrends, Inc. Updating firmware in a high availability enabled computer system
JP5439400B2 (ja) * 2011-01-31 2014-03-12 京セラドキュメントソリューションズ株式会社 画像形成装置
US8745614B2 (en) * 2011-05-13 2014-06-03 Lsi Corporation Method and system for firmware upgrade of a storage subsystem hosted in a storage virtualization environment
JP5939896B2 (ja) * 2012-06-12 2016-06-22 キヤノン株式会社 画像形成装置
TWI480799B (zh) * 2012-07-05 2015-04-11 Wistron Neweb Corp 嵌入式系統之韌體更新方法及設備
FR2993682B1 (fr) * 2012-07-20 2014-08-22 Oberthur Technologies Mise a jour d'un systeme d'exploitation pour element securise
JP2015146102A (ja) * 2014-02-03 2015-08-13 株式会社ワコム センサコントローラ、センサコントローラを備えたセンサデバイス、センサデバイスが搭載された電子機器およびアプリケーションソフトウェアの復旧方法
JP6482211B2 (ja) * 2014-09-03 2019-03-13 キヤノン株式会社 情報処理装置、その制御方法、及びプログラム
KR102261815B1 (ko) 2014-10-30 2021-06-07 삼성전자주식회사 펌웨어 업데이트 시간을 줄일 수 있는 데이터 저장 장치, 및 이를 포함하는 데이터 처리 시스템
JP6073854B2 (ja) * 2014-12-26 2017-02-01 京セラドキュメントソリューションズ株式会社 電子機器及びファームウェア復旧プログラム
US9524158B2 (en) * 2015-02-23 2016-12-20 Apple Inc. Managing firmware updates for integrated components within mobile devices
JP6408450B2 (ja) * 2015-10-26 2018-10-17 日立オートモティブシステムズ株式会社 自動車用電子制御装置
EP3220262B1 (en) * 2016-03-15 2018-06-13 Axis AB Device which is operable during firmware upgrade
KR20170126230A (ko) * 2016-05-09 2017-11-17 한국전자통신연구원 펌웨어 업데이트 장치 및 방법, 그리고 펌웨어 업데이트 시스템
TWI615705B (zh) * 2016-05-31 2018-02-21 瑞昱半導體股份有限公司 於電腦系統中重置記憶體的方法
JP6740789B2 (ja) * 2016-08-03 2020-08-19 富士通株式会社 ストレージ制御装置および記憶装置管理プログラム
JP6760813B2 (ja) * 2016-10-14 2020-09-23 日立オートモティブシステムズ株式会社 ソフトウェア更新装置、ソフトウェア更新方法、ソフトウェア更新システム
CN107391304B (zh) * 2017-07-26 2020-06-16 四川秘无痕科技有限责任公司 一种获取日立硬盘可用nv-ram的方法
ES2827790T3 (es) 2017-08-21 2021-05-24 Carrier Corp Sistema antiincendios y de seguridad que incluye bucle accesible por dirección y mejora automática de firmware
JP2019040376A (ja) * 2017-08-25 2019-03-14 株式会社明電舎 局所的データの書換方法
JP7069826B2 (ja) * 2018-02-27 2022-05-18 株式会社リコー 情報処理装置、ファームウェア更新方法、プログラム
JP2020017059A (ja) * 2018-07-25 2020-01-30 日本電気株式会社 情報処理装置、情報処理システム、情報処理方法及びプログラム

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH01110218A (ja) 1987-10-24 1989-04-26 Denki Kagaku Keiki Co Ltd 気体流量計及び気体流量制御装置
JP2000187588A (ja) * 1998-12-21 2000-07-04 Nikon Corp プログラム書き換え装置
JP2001331379A (ja) * 2000-05-22 2001-11-30 Nec Microsystems Ltd フラッシュメモリ更新プログラムの書き換え方法及び装置
JP2008084304A (ja) * 2006-09-01 2008-04-10 Ricoh Co Ltd 画像形成装置、プログラム更新方法及びプログラム

Family Cites Families (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH11110218A (ja) 1997-10-03 1999-04-23 Hitachi Ltd ファームウェア書き換え装置
US6311322B1 (en) 1998-03-09 2001-10-30 Nikon Corporation Program rewriting apparatus
US6640334B1 (en) * 1999-09-27 2003-10-28 Nortel Networks Limited Method and apparatus of remotely updating firmware of a communication device
US6574754B1 (en) * 2000-02-14 2003-06-03 International Business Machines Corporation Self-monitoring storage device using neural networks
US7200845B2 (en) * 2001-12-03 2007-04-03 Hewlett-Packard Development Company, L.P. System and method for high availability firmware load
US20040093597A1 (en) * 2002-11-05 2004-05-13 Rao Bindu Rama Firmware update system for facilitating firmware update in mobile handset related applications
FI116641B (fi) 2003-10-24 2006-01-13 Nokia Corp Menetelmä elektronisessa laitteessa olevan pikavalinnan muuttamiseksi, laitteen näyttöyksikkö sekä elektroninen laite
US7809836B2 (en) * 2004-04-07 2010-10-05 Intel Corporation System and method for automating bios firmware image recovery using a non-host processor and platform policy to select a donor system
WO2006133629A1 (fr) * 2005-06-15 2006-12-21 Huawei Technologies Co., Ltd. Procede et systeme de restauration automatique apres une panne de peripherique
US8286156B2 (en) * 2006-11-07 2012-10-09 Sandisk Technologies Inc. Methods and apparatus for performing resilient firmware upgrades to a functioning memory
JP4227641B2 (ja) * 2006-11-20 2009-02-18 キヤノン株式会社 情報処理装置及び情報処理装置の制御方法
US8776037B2 (en) * 2007-01-04 2014-07-08 International Business Machines Corporation Apparatus and method to update multiple devices disposed in a computing system
US20080168435A1 (en) * 2007-01-05 2008-07-10 David Tupman Baseband firmware updating
US9112891B2 (en) * 2007-02-02 2015-08-18 Sharp Laboratories Of America, Inc. Remote firmware management for electronic devices
US20090271780A1 (en) * 2008-04-24 2009-10-29 Moschip Semiconductor Technology Limited Automatic complete firmware upgrade
US8245214B2 (en) * 2008-06-05 2012-08-14 International Business Machines Corporation Reliably updating computer firmware while performing command and control functions on a power/thermal component in a high-availability, fault-tolerant, high-performance server
US8136108B2 (en) * 2008-09-03 2012-03-13 Computime, Ltd Updating firmware with multiple processors
US8892699B2 (en) * 2008-12-31 2014-11-18 Schneider Electric USA, Inc. Automatic firmware updates for intelligent electronic devices

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH01110218A (ja) 1987-10-24 1989-04-26 Denki Kagaku Keiki Co Ltd 気体流量計及び気体流量制御装置
JP2000187588A (ja) * 1998-12-21 2000-07-04 Nikon Corp プログラム書き換え装置
JP2001331379A (ja) * 2000-05-22 2001-11-30 Nec Microsystems Ltd フラッシュメモリ更新プログラムの書き換え方法及び装置
JP2008084304A (ja) * 2006-09-01 2008-04-10 Ricoh Co Ltd 画像形成装置、プログラム更新方法及びプログラム

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170099405A1 (en) * 2015-10-02 2017-04-06 Hajime Takayama Control apparatus and control method
US11301229B2 (en) 2018-03-29 2022-04-12 Nec Corporation System update device and system update method

Also Published As

Publication number Publication date
US20110131563A1 (en) 2011-06-02
EP2330507A1 (en) 2011-06-08
CN102165422B (zh) 2014-06-04
JP5113700B2 (ja) 2013-01-09
JP2010079440A (ja) 2010-04-08
US8549510B2 (en) 2013-10-01
CN102165422A (zh) 2011-08-24
EP2330507A4 (en) 2012-05-02

Similar Documents

Publication Publication Date Title
WO2010035596A1 (ja) ファームウェア更新装置及び方法
JP5346253B2 (ja) ファームウェア更新システム、及び情報機器、並びにプログラム
KR101636870B1 (ko) 최소 부트 이미지의 생성 방법 및 장치
WO2010116835A1 (ja) ファームウェア更新システム、ファームウェア配信サーバ、及びファームウェア組み込み機器、並びにプログラム
CN104572229A (zh) 嵌入式系统的固件升级方法以及固件升级装置
JP6072352B2 (ja) ディスク配信システム
JP2008084029A (ja) 仮想マシン管理システム
JP5728812B2 (ja) 分散型情報処理システム及び分散ストレージシステム
JP2007058699A (ja) 情報処理装置、情報処理装置制御プログラム、情報処理装置制御方法
JP5387767B2 (ja) 実行中のプログラムの更新技術
JP7231807B2 (ja) 通信装置及び情報処理方法
CN105511904A (zh) 一种自动更新快捷窗口的方法及装置
JP2014089497A (ja) 情報処理装置
JP2008217202A (ja) ディスクアレイ装置及びファームウェア更新方法
JP6160688B2 (ja) 情報処理装置、情報処理方法、及び情報処理プログラム
JPWO2012077604A1 (ja) 処理装置、プログラム更新方法、およびプログラム
JP6149624B2 (ja) ファームウェア実行装置、ファームウェア実行方法、コンピュータ・プログラム、および、コンピュータ装置
JP5094531B2 (ja) ソフトウェア書き換え装置及びソフトウェア書き換え方法及びソフトウェア書き換えプログラム
TWI448967B (zh) 軟體更新方法與電腦可讀取媒體
JP2008198152A (ja) 冗長構成を有するコンピュータシステム及びコンピュータシステムの系切り換え方法
WO2021153224A1 (ja) 情報処理装置および情報処理方法
JP2009251673A (ja) 情報処理装置、ｏｓのアップデート時間短縮方法およびプログラム
JP6702060B2 (ja) クラスタシステム及びサーバ制御プログラム
JP2005321967A (ja) 情報処理装置
CN117873676A (zh) 控制系统的启动方法、装置、控制系统及计算机程序产品

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 200980137476.7

Country of ref document: CN

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 09816013

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 13054943

Country of ref document: US

REEP Request for entry into the european phase

Ref document number: 2009816013

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2009816013

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE